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Copyright Statement 

[0001] a portion of the disclosure of this patent document con- 
tains material which is subject to copyright protection. 
The copyright owner has no objection to the facsimile re- 
production by anyone of the patent document or the 
patent disclosure as it appears in the Patent and Trade- 
mark Office patent file or records, but otherwise reserves 
all copyright rights whatsoever. 
Appendix Data 

[0002] Computer Program Listing Appendix under Sec. 1.52(e): 
This application includes a transmittal under 37 C.F.R. 
Sec. 1.52(e) of a Computer Program Listing Appendix. The 
Appendix, which comprises text file(s) that are IBM-PC 
machine and Microsoft Windows Operating System com- 
patible, includes the below-listed file(s). All of the mate- 
rial disclosed in the Computer Program Listing Appendix 



can be found at the U.S. Patent and Trademark Office 
archives and is hereby incorporated by reference into the 
present application. 
[0003] object Description: SourceCode.txt, created: 3/12/2004, 
7:26am, size: 32.3KB; Object ID: File No. 1; Object Con- 
tents: Source Code. 
Background of Invention 

[0004] 1. Field of the Invention 

[0005] The present invention relates generally to data processing 
environments and, more particularly, to a system provid- 
ing methodology for consolidation of financial informa- 
tion. 

[0006] 2. Description of the Background Art 

[0007] Historically, banking operations have involved a number 
of time consuming and tedious tasks for both individuals 
and businesses requiring banking services. Examples of 
time consuming consumer banking processes include vis- 
iting a branch or bank center, paying bills by paper check 
(and mailing them), and balancing checkbooks. Busi- 
nesses also have had similar issues, but in the case of 
business banking an even larger number and types of 
banking transactions (particularly, a larger number of 



transactions) are typically involved. 

[0008] | n addition, banking operations have also historically in- 
volved dealing with large quantities of information, much 
of which was historically maintained and exchanged in 
paper format. More recently, the exchange of financial in- 
formation between banking and financial organizations 
has been automated. Banks having been exchanging in- 
formation electronically for a number of years and today 
most of the information exchanges between banks is han- 
dled electronically. 

[0009] while banks have exchanged information electronically for 
a number of years, for much of this period most con- 
sumers and businesses continued to conduct banking 
transactions in the traditional, paper-oriented fashion. 
However, with the growth of the Internet, online banking 
has automated a number of these processes for busi- 
nesses and consumers. Online banking can save time by 
enabling bank customers to access their accounts and 
perform various banking transactions when (and where) it 
is convenient. As a result, online banking has been grow- 
ing in popularity in recent years. 

[0010] Another recent trend is that businesses and other organi- 
zations are facing an increasing need to cut costs and de- 



liver services with fewer resources while, at the same time, 
finding new sources of revenue. To meet this challenge, 
corporate treasurers and other financial professionals are 
increasingly seeking banking solutions that allow them to 
efficiently manage their entire organization's cash posi- 
tion in an easy-to-use format. In addition, by moving 
from paper-based processing to electronic processing, 
corporations are able to eliminate inefficient and error 
prone processes. 
1 ] Although online banking provides increased efficiency and 
ease-of-use, problems remain with the delivery of online 
banking services. One problem to be addressed by banks 
in providing consumers and businesses with online access 
to banking information is that this information is typically 
maintained in a number of different formats and at a 
number of different locations. In addition, banks and fi- 
nancial institutions also usually have a number of differ- 
ent sources of financial information (e.g., BAI, SWIFT, 
back-end, and/or proprietary files). For example, a given 
bank may typically exchange files containing banking in- 
formation with other banks (including federal banks) on a 
regular basis (e.g., several times per day). The bank may, 
for instance, receive files in a BAI (Bank Administration In- 



stitute) file format from other banks four times per day. In 
addition to the information received in files from other 
banks, the bank also typically has other "live" 
(user-accessible) information that is available in the 
bank's bank-end systems. This "live" information is often 
maintained in proprietary formats in the bank's internal 
systems. 

[0012] Bank customers want to receive a complete, consolidated 
report of activity relating to a particular account in a con- 
venient, easy to use format. However, the number of 
sources of banking information and the different formats 
in which such information is maintained makes it difficult 
for the bank to consolidate and report accurate and com- 
plete information to its customers. Also, banking informa- 
tion received from external sources may also duplicate 
entries that have already been made in internal systems, 
so the solution needs to be able to reconcile the informa- 
tion received from different sources. 

[0013] Another issue to be addressed is that the quantity of in- 
formation relating to particular accounts may be quite 
large, particularly in the case of accounts maintained by a 
large corporation. This volume of information can make it 
difficult for the bank to consolidate and report account 



information to the customer in a manner in which the 
customer can understand. On a given day, a corporate 
customer may have hundreds or even thousands of trans- 
actions relating to particular accounts. A member of a 
corporation's financial staff may have difficulty under- 
standing and using transaction information relating to 
these accounts unless he or she can easily navigate 
through this information (e.g., paging through the infor- 
mation using a browser interface or the like). 
[0014] what is needed is a solution which consolidates financial 
information from a number of different sources, enabling 
accurate and complete information to be presented in a 
format that is easy to navigate and use. Ideally, the solu- 
tion should provide a means for storing historical account 
information which enables accurate and complete infor- 
mation to be retrieved efficiently. The solution should also 
facilitate the viewing and navigation of large quantities of 
data, such as large collections of financial transactions. 
The present invention provides a solution for these and 
other needs. 
Summary of Invention 

[0015] a system providing methodology for consolidation of fi- 
nancial information is described. In one embodiment, for 



example, a system of the present invention is described 
for consolidating financial transaction information from 
multiple sources for presentation to a user, the system 
comprises: a file importer for importing data files from a 
first source and processing each data file to create parsed 
information for each transaction present in the data file 
and represent any additional information present in the 
data file in Extensible Markup Language (XML) format; a 
data consolidator for receiving parsed information from 
the file importer, consolidating the parsed information 
with transaction information from a user-accessible sys- 
tem to create consolidated transaction records, assigning 
a unique identifier to each consolidated transaction record 
for an account, and storing the consolidated transaction 
records; and a reporting module for receiving a request 
for financial transaction information for a particular ac- 
count and presenting consolidated transaction records for 
the particular account to the user in response to the re- 
quest, wherein the user may navigate through the consol- 
idated transaction records based upon the unique identi- 
fier. 

[0016] | n another embodiment, for example, a computer-im- 
plemented method of the present invention is described 



for consolidating and presenting financial information to a 
user, the method comprises steps of: importing data files 
of different types; for each particular type imported, load- 
ing a file adapter suited for processing that particular 
type; for each imported data file, creating parsed informa- 
tion from the data file that identifies each transaction 
present in the data file with a unique sequence number, 
and that represents any additional information present in 
the data file in XML format; creating consolidated financial 
information by storing all parsed information in a consoli- 
dation repository; receiving a user request at a user- 
accessible system for information about a particular fi- 
nancial account; and in response to the user request, de- 
termining financial information in the user-accessible 
system and the consolidation repository that is most cur- 
rent for the particular financial account, and presenting 
that financial information to the user. 
[0017] | n yet another embodiment, for example, a computer- 
implemented system of the present invention is described 
for consolidating and presenting financial information to a 
user comprises: a file importer for importing data files of 
different types; a plurality of file adapters, each file 
adapter suited for processing a particular type of data file 



imported by creating parsed information from the data file 
that identifies each transaction present in the data file 
with a unique sequence number, and by representing any 
additional information present in the data file in XML for- 
mat for each imported data file; a consolidation repository 
for storing consolidated financial information; a user- 
accessible system for receiving a user request for infor- 
mation about a particular financial account; and a module 
for determining financial information in the user- 
accessible system and the consolidation repository that is 
most current for the particular financial account, and pre- 
senting that financial information to the user. 
Brief Description of Drawings 

[0018] pig. 1 is a very general block diagram of a computer sys- 
tem (e.g., an IBM-compatible system) in which software- 
implemented processes of the present invention may be 
embodied. 

[0019] pig. 2 is a block diagram of a software system for control- 
ling the operation of the computer system. 

[0020] Fig. 3 is a block diagram of an environment in which the 
system of the present invention may be preferably em- 
bodied. 

[0021] Fig. 4 is a block diagram of an environment illustrating 



the components of the system of the present invention 
and their operations in further detail. 
[0022] pigs. 5A-B comprise a single flowchart illustrating the op- 
erations of the system of the present invention in consoli- 
dating financial information and presenting consolidated 
financial information to a user. 
Detailed Description 

Glossary 

[0023] The following definitions are offered for purposes of illus- 
tration, not limitation, in order to assist with understand- 
ing the discussion that follows. 

[0024] BAI: The BAI (Bank Administration Institute) file format is 
considered the de-facto standard by most banks and cor- 
porations. While all banks claim to conform to the BAI for- 
mat, banks frequently customize BAI files by adding their 
own fields or lines to the files. 

[0025] Bytecode: A virtual machine executes virtual machine low- 
level code instructions called bytecodes. Both the Sun Mi- 
crosystems Java virtual machine and the Microsoft .NET 
virtual machine provide a compiler to transform the re- 
spective source program (i.e., a Java program or a C# pro- 
gram, respectively) into virtual machine bytecodes. 



[0026] Compiler: A compiler is a program which translates source 
code into binary code to be executed by a computer. The 
compiler derives its name from the way it works, looking 
at the entire piece of source code and collecting and reor- 
ganizing the instructions. Thus, a compiler differs from an 
interpreter which analyzes and executes each line of code 
in succession, without looking at the entire program. A 
"Java compiler" translates source code written in the Java 
programming language into bytecode for the Java virtual 
machine. 

[0027] HTML: HTML stands for HyperText Markup Language, the 
authoring language used to create documents on the 
World Wide Web. HTML defines the structure and layout of 
a Web document by using a variety of tags and attributes. 
For further description of HTML, see e.g., "HTML 4.01 
Specification", a World Wide Web consortium recommen- 
dation dated December 24, 1999, the disclosure of which 
is hereby incorporated by reference. A copy of this speci- 
fication is available via the Internet (e.g., currently at 
www.w3.org/TR/REC-html40). 

[0028] J2EE: "J 2 EE" is an abbreviation for Java 2 Platform Enter- 
prise Edition, which is a platform-independent, Java- 
centric environment from Sun Microsystems for develop- 



ing, building and deploying Web-based enterprise appli- 
cations. The J2EE platform consists of a set of services, 
APIs, and protocols that provide functionality for develop- 
ing multi-tiered, web-based applications. For further in- 
formation on J2EE, see e.g., "Java 2 Platform, Enterprise 
Edition Specification, version 1.4", from Sun Microsys- 
tems, Inc., the disclosure of which is hereby incorporated 
by reference. A copy of this specification is available via 
the Internet (e.g., currently at 
java.sun.com/j2ee/j2ee-l_4-fr-spec.pdf). 
[0029] j ava: j ava j S a general purpose programming language de- 
veloped by Sun Microsystems. Java is an object-oriented 
language similar to C++, but simplified to eliminate lan- 
guage features that cause common programming errors. 
Java source code files (files with a Java extension) are 
compiled into a format called bytecode (files with a .class 
extension), which can then be executed by a Java inter- 
preter. Compiled Java code can run on most computers 
because Java interpreters and runtime environments, 
known as Java virtual machines (VMs), exist for most op- 
erating systems, including UNIX, the Macintosh OS, and 
Windows. Bytecode can also be converted directly into 
machine language instructions by a just-in-time QIT) 



compiler. Further description of the Java Language envi- 
ronment can be found in the technical, trade, and patent 
literature; see e.g., Gosling, J. et al., "The Java Language 
Environment: A White Paper", Sun Microsystems Computer 
Company, October 1995, the disclosure of which is hereby 
incorporated by reference. For additional information on 
the Java programming language (e.g., version 2), see e.g., 
"Java 2 SDK, Standard Edition Documentation, version 
1.4.2", from Sun Microsystems, the disclosure of which is 
hereby incorporated by reference. A copy of this docu- 
mentation is available via the Internet (e.g., currently at 
java.sun.com/j2se/ 1. 4. 2/docs/index. html). 
[0030] JavaScript: JavaScript was designed by Netscape as an 
easy-to-use object-oriented scripting language that 
serves as an adjunct to the Java programming language. 
JavaScript is a small, lightweight language that is designed 
to be embedded in other products and applications, such 
as Web browsers. Inside a host environment, JavaScript 
can be connected to the objects of its environment to 
provide programmatic control over such objects. 
JavaScript code can be added to standard HTML pages to 
create interactive documents and has found considerable 
use in the creation of interactive Web-based forms. Most 



modern browsers, including those from Microsoft and 
Netscape, contain JavaScript support. For additional infor- 
mation on JavaScript, see e.g., "Core JavaScript Guide 1.5", 
from Netscape, the disclosure of which is hereby incorpo- 
rated by reference. A copy of this documentation is avail- 
able via the Internet (e.g., currently at 
devedge.netscape.com). 
[0031] javaServer Pages QSP) is a web-scripting technology simi- 
lar to Netscape server-side JavaScript (SSJS) or Microsoft 
Active Server Pages (ASP). JSP is a presentation layer tech- 
nology that sits on top of a Java servlets model and makes 
working with HTML easier. It allows a developer to mix 
static HTML content with server-side scripting to produce 
dynamic output. By default, JSP uses Java as its scripting 
language; however, the specification allows other lan- 
guages to be used, just as ASP can use other languages 
(such as JavaScript and VBScript). For further description 
of JavaServer Pages, see e.g., "JSR-000 152 JavaServer 
Pages .0 Specification", available from Sun Microsystems. 
A copy of this specification is available via the Internet 
(e.g., currently at 

jcp.org/aboutJava/communityprocess/final/jsrl52/). 
[0032] Network: A network is a group of two or more systems 



linked together. There are many types of computer net- 
works, including local area networks (LANs), virtual private 
networks (VPNs), metropolitan area networks (MANs), 
campus area networks (CANs), and wide area networks 
(WANs) including the Internet. As used herein, the term 
"network" refers broadly to any group of two or more 
computer systems or devices that are linked together 
from time to time (or permanently). 

[0033] Portal: A portal provides an individualized or personalized 
view of multiple resources (e.g., Web sites) and services. A 
portal typically offers a single access point (e.g., browser 
page) providing access to a range of information and ap- 
plications. A portal assembles information from a number 
of different sources (e.g., Web sites and applications) en- 
abling a user to quickly receive information without hav- 
ing to navigate to a number of different Web sites. A por- 
tal also typically enables a user to obtain a personalized 
view of information and applications by organizing and 
grouping information and services for presentation to 
users. A portal may be considered to be composed of one 
or more portlets. 

[0034] TCP/IP: TCP/IP stands for Transmission Control Protocol/ 
Internet Protocol, the suite of communications protocols 



used to connect hosts on the Internet. TCP/IP uses several 
protocols, the two main ones being TCP and IP. TCP/IP is 
built into the UNIX operating system and is used by the 
Internet, making it the de facto standard for transmitting 
data over networks. For an introduction to TCP/IP, see 
e.g., "RFC 1180: A TCP/IP Tutorial", the disclosure of 
which is hereby incorporated by reference. A copy of RFC 
1180 is available via the Internet (e.g., currently at 
www . i e tf . o rg / rf c / rf c 1 1 8 0 . txt) . 
[0035] XML: XML stands for Extensible Markup Language, a spec- 
ification developed by the World Wide Web Consortium 
(W3C). XML is a pared-down version of the Standard Gen- 
eralized Markup Language (SGML), a system for organiz- 
ing and tagging elements of a document. XML is designed 
especially for Web documents. It allows designers to cre- 
ate their own customized tags, enabling the definition, 
transmission, validation, and interpretation of data be- 
tween applications and between organizations. For further 
description of XML, see e.g., "Extensible Markup Language 
(XML) 1.0", (2nd Edition, October 6, 2000) a recom- 
mended specification from the W3C, the disclosure of 
which is hereby incorporated by reference. A copy of this 
specification is available via the Internet (e.g., currently at 



www.w3.org /TR/REC-xml). 
Introduction 

[0036] Referring to the figures, exemplary embodiments of the 

invention will now be described. The following description 
will focus on the presently preferred embodiment of the 
present invention, which is implemented in desktop and/ 
or server software (e.g., driver, application, or the like) 
operating in an Internet-connected environment running 
under an operating system, such as the Microsoft Win- 
dows operating system. The present invention, however, 
is not limited to any one particular application or any par- 
ticular environment. Instead, those skilled in the art will 
find that the system and methods of the present invention 
may be advantageously embodied on a variety of different 
platforms, including Macintosh, Linux, Solaris, UNIX, 
FreeBSD, and the like. Therefore, the description of the 
exemplary embodiments that follows is for purposes of il- 
lustration and not limitation. The exemplary embodiments 
are primarily described with reference to block diagrams 
or flowcharts. As to the flowcharts, each block within the 
flowcharts represents both a method step and an appara- 
tus element for performing the method step. Depending 
upon the implementation, the corresponding apparatus 



element may be configured in hardware, software, 
firmware, or combinations thereof. 
Computer-based implementation 



[0037] Basic system hardware (e.g., for desktop and server computers) 

[0038] The present invention may be implemented on a conven- 
tional or general-purpose computer system, such as an 
IBM-compatible personal computer (PC) or server com- 
puter. Fig. 1 is a very general block diagram of a com- 
puter system (e.g., an IBM-compatible system) in which 
software-implemented processes of the present invention 
may be embodied. As shown, system 100 comprises a 
central processing unit(s) (CPU) or processor(s) 101 cou- 
pled to a random-access memory (RAM) 102, a read-only 
memory (ROM) 103, a keyboard 106, a printer 107, a 
pointing device 108, a display or video adapter 104 con- 
nected to a display device 105, a removable (mass) stor- 
age device 115 (e.g., floppy disk, CD-ROM, CD-R, CD-RW, 
DVD, or the like), a fixed (mass) storage device 116 (e.g., 
hard disk), a communication (COMM) port(s) or inter- 
face(s) 110, a modem 112, and a network interface card 
(NIC) or controller 111 (e.g., Ethernet). Although not 
shown separately, a real time system clock is included 



with the system 100, in a conventional manner. 
[0039] CPU 101 comprises a processor of the Intel Pentium family 
of microprocessors. However, any other suitable proces- 
sor may be utilized for implementing the present inven- 
tion. The CPU 101 communicates with other components 
of the system via a bi-directional system bus (including 
any necessary input/output (I/O) controller circuitry and 
other "glue" logic). The bus, which includes address lines 
for addressing system memory, provides data transfer be- 
tween and among the various components. Description of 
Pentium-class microprocessors and their instruction set, 
bus architecture, and control lines is available from Intel 
Corporation of Santa Clara, CA. Random-access memory 
102 serves as the working memory for the CPU 101. In a 
typical configuration, RAM of sixty-four megabytes or 
more is employed. More or less memory may be used 
without departing from the scope of the present inven- 
tion. The read-only memory (ROM) 103 contains the basic 
input/output system code (BIOS) — a set of low-level rou- 
tines in the ROM that application programs and the oper- 
ating systems can use to interact with the hardware, in- 
cluding reading characters from the keyboard, outputting 
characters to printers, and so forth. 



[0040] Mass storage devices 115, 116 provide persistent storage 
on fixed and removable media, such as magnetic, optical 
or magnetic-optical storage systems, flash memory, or 
any other available mass storage technology. The mass 
storage may be shared on a network, or it may be a dedi- 
cated mass storage. As shown in Fig. 1, fixed storage 116 
stores a body of program and data for directing operation 
of the computer system, including an operating system, 
user application programs, driver and other support files, 
as well as other data files of all sorts. Typically, the fixed 
storage 116 serves as the main hard disk for the system. 

[0041] | n basic operation, program logic (including that which 
implements methodology of the present invention de- 
scribed below) is loaded from the removable storage 115 
or fixed storage 116 into the main (RAM) memory 102, for 
execution by the CPU 101. During operation of the pro- 
gram logic, the system 100 accepts user input from a 
keyboard 106 and pointing device 108, as well as speech- 
based input from a voice recognition system (not shown). 
The keyboard 106 permits selection of application pro- 
grams, entry of keyboard-based input or data, and selec- 
tion and manipulation of individual data objects displayed 
on the screen or display device 105. Likewise, the pointing 



device 108, such as a mouse, track ball, pen device, or the 
like, permits selection and manipulation of objects on the 
display device. In this manner, these input devices sup- 
port manual user input for any process running on the 
system. 

[0042] The computer system 100 displays text and/or graphic 
images and other data on the display device 105. The 
video adapter 104, which is interposed between the dis- 
play 105 and the system's bus, drives the display device 
105. The video adapter 104, which includes video memory 
accessible to the CPU 101, provides circuitry that converts 
pixel data stored in the video memory to a raster signal 
suitable for use by a cathode ray tube (CRT) raster or liq- 
uid crystal display (LCD) monitor. A hard copy of the dis- 
played information, or other information within the sys- 
tem 100, may be obtained from the printer 107, or other 
output device. Printer 107 may include, for instance, an 
HP LaserJet printer (available from Hewlett Packard of Palo 
Alto, CA), for creating hard copy images of output of the 
system. 

[0043] The system itself communicates with other devices (e.g., 
other computers) via the network interface card (NIC) 111 
connected to a network (e.g., Ethernet network, Bluetooth 



wireless network, or the like), and/or modem 112 (e.g., 
56K baud, ISDN, DSL, or cable modem), examples of 
which are available from 3Com of Santa Clara, CA. The 
system 100 may also communicate with local occasion- 
ally-connected devices (e.g., serial cable-linked devices) 
via the communication (COMM) interface 110, which may 
include a RS-232 serial port, a Universal Serial Bus (USB) 
interface, or the like. Devices that will be commonly con- 
nected locally to the interface 110 include laptop comput- 
ers, handheld organizers, digital cameras, and the like. 

[0044] IBM-compatible personal computers and server computers 
are available from a variety of vendors. Representative 
vendors include Dell Computers of Round Rock, TX, 
Hewlett-Packard of Palo Alto, CA, and IBM of Armonk, NY. 
Other suitable computers include Apple-compatible com- 
puters (e.g., Macintosh), which are available from Apple 
Computer of Cupertino, CA, and Sun Solaris workstations, 
which are available from Sun Microsystems of Mountain 
View, CA. 

[0045] Basic system software 

[0046] Fig. 2 is a block diagram of a software system for control- 
ling the operation of the computer system 100. As shown, 
a computer software system 200 is provided for directing 



the operation of the computer system 100. Software sys- 
tem 200, which is stored in system memory (RAM) 102 
and on fixed storage (e.g., hard disk) 116, includes a ker- 
nel or operating system (OS) 210. The OS 210 manages 
low-level aspects of computer operation, including man- 
aging execution of processes, memory allocation, file in- 
put and output (I/O), and device I/O. One or more appli- 
cation programs, such as client application software or 
"programs" 201 (e.g., 201a, 201b, 201c, 201d) may be 
"loaded" (i.e., transferred from fixed storage 116 into 
memory 102) for execution by the system 100. The appli- 
cations or other software intended for use on the com- 
puter system 100 may also be stored as a set of down- 
loadable computer-executable instructions, for example, 
for downloading and installation from an Internet location 
(e.g., Web server). 
[0047] System 200 includes a graphical user interface (GUI) 215, 
for receiving user commands and data in a graphical (e.g., 
"point-and-click") fashion. These inputs, in turn, may be 
acted upon by the system 100 in accordance with instruc- 
tions from operating system 210, and/or client applica- 
tion module(s) 201. The GUI 215 also serves to display the 
results of operation from the OS 210 and application(s) 



201, whereupon the user may supply additional inputs or 
terminate the session. Typically, the OS 210 operates in 
conjunction with device drivers 220 (e.g., "Winsock" driver 
— Windows' implementation of a TCP/IP stack) and the 
system BIOS microcode 230 (i.e., ROM-based microcode), 
particularly when interfacing with peripheral devices. OS 
210 can be provided by a conventional operating system, 
such as Microsoft Windows 9x, Microsoft Windows NT, Mi- 
crosoft Windows 2000, or Microsoft Windows XP, all avail- 
able from Microsoft Corporation of Redmond, WA. Alter- 
natively, OS 210 can also be an alternative operating sys- 
tem, such as the previously mentioned operating systems. 
[0048] The above-described computer hardware and software are 
presented for purposes of illustrating the basic underlying 
desktop and server computer components that may be 
employed for implementing the present invention. For 
purposes of discussion, the following description will 
present examples in which it will be assumed that there 
exists a "server" (e.g., Web server) that communicates with 
one or more "clients" (e.g., desktop computers). The 
present invention, however, is not limited to any particular 
environment or device configuration. In particular, a 
client/server distinction is not necessary to the invention, 



but is used to provide a framework for discussion. In- 
stead, the present invention may be implemented in any 
type of system architecture or processing environment ca- 
pable of supporting the methodologies of the present in- 
vention presented in detail below. 
Overview of system and methodology for consolidation of 

FINANCIAL INFORMATION 

[0049] introduction 

[0050] Before describing the operations of the system and 

methodology of the present invention for consolidation of 
financial information, the environment in which the sys- 
tem may be implemented will be briefly described. In its 
currently preferred embodiment, the present invention is 
commercially embodied as a component of the Financial 
Fusion (trademark) Corporate Banking Solution 
("Corporate Banking Solution"). The Corporate Banking 
Solution, which is based on Java 2 Enterprise Edition Q2EE) 
components, allows users to manage a wide variety of 
banking services from a single Web portal providing con- 
nectivity to a number of back-end systems. The solution 
uses JavaServer Pages QSPs) to provide information to cus- 
tomers in a Web portal and includes back-endsystem con- 
nectivity tools facilitating customization of the solution to 



address specific customer requirements. 

[0051] The Corporate Banking Solution design is modular; it is 

based on a series of application components that are inte- 
grated and yet can be customized to address particular 
customer requirements. It includes a framework that sup- 
ports middleware services and provides tools to enhance 
and support customization and back-end integration. The 
solution includes three tiers: a Web tier; an application 
tier; and a back-end tier. These tiers work together to 
create the user interface (Ul) and business logic solutions 
that make up the Corporate Banking Solution. Each of 
these tiers will be briefly described. 

[0052] The Web tier includes static and dynamic presentation 

layers which work together to create a dynamic Web user 
interface. To develop a specific user interface (Ul), a Web 
designer creates the HTML content and images for the JSP 
pages, and a Web developer would create supporting JSP 
tag libraries and beans. All of these elements reside on 
the Web tier. The static presentation layer typically con- 
sists of static HTML files and images that reside on a Web 
server. When a user accesses the portal (i.e., Web server), 
this layer provides any static information to the user in- 
terface. If the user requests information from a back-of- 



fice database or makes some other interactive request, 
these actions are redirected to JSPs in the dynamicpresen- 
tation layer on the Corporate Banking Solution application 
server. The dynamic presentation layer consists of the 
JSPs, tag libraries, XML files, services, tasks, and Java 
Beans that provide dynamic content delivery over the Web. 
JSPs are redirected and processed by the application 
server. HTML is issued from the JSP layer and displayed 
through a Web browser. 

[0053] The Application tier implements the business logic to 
complete requests made by the user using the Web tier 
(i.e., user interface). The Application tier includes the Cor- 
porate Banking and Business Central modules and a Core 
API for receiving requests from the user interface (Ul), for- 
warding them to the back-end systems, and returning re- 
sponses from the back-end systems to the Ul. 

[0054] The solution is designed to operate with existing bank 
back-office/back-end systems without requiring any 
changes to these systems. Connectivity is established 
through existing access to the back-end systems using a 
variety of communications protocols supported by the so- 
lution. Additional external systems may include content 
providers, other financial institutions, billers, bill fulfill- 



ment providers, and so forth. 
[0055] a bill payment and transfer warehouse component trans- 
lates data entered via the Corporate Banking Solution into 
the respective API calls of the back-office systems. Back- 
office systems perform the requested work and return the 
results to the user through the task-specific user interface 
(Ul). Requests entered through the user interface can re- 
quire information from a local operational database or 
from back-office systems. When a back-office system re- 
turns information, it is forwarded to the appropriate sub- 
system. 

[0056] The Corporate Banking Solution provides an n-tier com- 
puting environment in which the business logic and data 
access are separate from the presentation and from each 
other, and only the presentation view resides on the 
client. The solution enables existing applications to access 
business logic and multiple data sources in a Web-based 
or distributed computing environment. Using an n-tier 
solution improves availability and scalability and provides 
improved access to the Corporate Banking Solution portal. 

[0057] pig. 3 is a block diagram of an environment 300 in which 
the system of the present invention may be preferably 
embodied. As shown, the Corporate Banking Solution in 



which the present invention is embodied comprises of a 
number of modules and supporting technologies and 
components. The browsers 311, 313 represent clients 
connected to the corporate banking module 320 and 
business central module 325, respectively. The corporate 
banking module 320 provides theJSPs, tasks, services, 
and beans that make up the core of the Corporate Banking 
Solution. Modules provided by the Corporate Banking So- 
lution include administration, account management, cash 
management, positive pay, controlled disbursements, 
lockbox, payments and transfers, ACH and tax payments, 
reporting, alerts, messages, and check imaging. 
[0058] Supporting applications and services are provided through 
the Financial Fusion Server 330. As shown, the services 
provided by the Financial Fusion Server 330 include, 
among others, entitlements, approvals, billpay, and, of 
particular interest, a data consolidator and a file importer 
which implement core methodology of the present inven- 
tion for consolidation of financial information. The Finan- 
cial Fusion Server 330 is connected to a number of back- 
end systems and databases, including a host (back-end) 
340, a data consolidator (repository) 350, a bill payment 
and transfer warehouse 360, a transaction warehouse 



365, an entitlements database 370, a portal/content 
server 380, an (universal) alerts engine 385, a logging/ 
reporting/imaging repository(ies) 390, an approvals sys- 
tem (module) 395, and other data stores and repositories 
375. The following discussion will focus on those modules 
of the Corporate Banking Solution which implement the 
methodology of the present invention for consolidation of 
financial information. 
[0059] Consolidation, storage, and display of financial information. 

[0060] The system and methodology of the present invention 

provides a single, local repository for banking/account in- 
formation that consolidates information that may origi- 
nate from a number of different sources, including BAI 
files, SWIFT, back-end systems, and proprietary files. The 
system stores information from these different sources in 
a central repository (sometimes referred to herein as the 
"data consolidator repository") in a manner which im- 
proves the performance of the retrieval of banking/ac- 
count information compared to prior solutions which typi- 
cally provide for retrieval of the information from a re- 
mote back-end (BE) system. The system provides a means 
for efficiently storing historical account data. In addition, 
it provides common reporting schemes and paging mech- 



anisms which provide users with easy access to the infor- 
mation in the data consolidator repository. The paging 
mechanisms supported by the present invention include a 
paging application programming interface (API) for large 
datasets, such as large collections of transactions. As de- 
scribed below, the paging API enables the solution to 
present financial information to users in a manageable 
form that facilitates user navigation of the information. 

[0061] The system and methodology of the present invention 

also provides for extensibility. Each customer (e.g., bank 
or other financial institution) may have its own custom in- 
formation available in BAI files and/or in the back-end 
systems that provide information to the data consolidator. 
A file importer module processes financial institution-sup- 
plied files (for example, BAI files) with each type of file 
handled by a particular file adapter. The file importer pro- 
vides a pluggable architecture in that it can be extended 
to support additional file types, including proprietary file 
types. For example, a particular bank can write additional 
file adapters to support particular proprietary file types 
used within the bank. 

[0062] Another important aspect of the system and methodology 
of the present invention is that the solution provides flex- 



ibility to enable imported files (e.g., BAI files) to be "un- 
done" when necessary. On occasion BAI files can contain 
errors that need to be corrected. However, correcting 
these errors can result in complications in providing the 
paging/navigation support for presenting the financial in- 
formation to users. The present invention provides two 
paging schemes for enabling imported files to be "un- 
done". A customer (e.g., a bank) typically selects one of 
these two paging schemes depending on the frequency of 
bad files (i.e., files with errors) that are encountered and 
various other factors. The components of the currently 
preferred embodiment of the system of the present inven- 
tion will next be described. 
System components 

[0063] Fig. 4 is a block diagram of an environment 400 illustrat- 
ing the components of the system of the present inven- 
tion and their operations in further detail. As shown, envi- 
ronment 400 includes a scheduler 410, a file importer 
420, a file adapter(s) 430, a data consolidator 450, a 
repository 460, a live system 470, a reporting module 
480, and an online data view 490. As also shown at Fig. 4, 
BAI or other data files 445 are received by the file adapter 
430. These components of the system of the present in- 



vention and their operations are described below. 

[0064] The scheduler 410 provides logic for triggering events. 
For example, a bank using the system of the present in- 
vention may receive a set of BAI files from a federal bank 
four times per day. In this case, the bank would set up the 
scheduler 410 to provide that four times per day the 
scheduler 410 would invoke the file importer 420 for pro- 
cessing the files (e.g., BAI files) received from the federal 
bank. The scheduler 410 would typically call the file im- 
porter 420 passing a parameter indicating the type of files 
(e.g., files of type BAI) that are to be processed. 

[0065] when invoked by the scheduler 410, the file importer 420 
loads the appropriate file adapter 430 for processing the 
type of files indicated by the scheduler 410. For example, 
if the specified file type is BAI, the file importer 420 loads 
a BAI file adapter. However, if another file type was speci- 
fied (e.g., a proprietary bank file type), a different file 
adapter would be loaded from the file adapter(s) 430. The 
file adapter 430 processes each of the data files 445 it re- 
ceives (e.g., in a configured directory) and it knows how to 
parse the file format of these data files. For example, a 
BAI file adapter processes BAI data files 445 as shown at 
Fig. 4. Currently, the file adapter(s) 430 processes data 



files and converts the file data into a Java representation. 
In processing the files, the file adapter 430 invokes vari- 
ous application programming interfaces (APIs) on the data 
consolidator 450 to store the data in the repository 460. 

[0066] one of the complications in processing data files and 
storing them in the repository 460 is that banks (and 
other financial institutions) frequently customize and/or 
extend the BAI file format to provide additional fields or 
lines to the BAI files. Accordingly, the system of the 
present invention must allow for the inclusion of addi- 
tional (extra) information in the BAI files. The data consol- 
idator 450 provides for handling and storing this addi- 
tional (or "extra") information which is not defined as a 
standard data element in the repository 460. In the cur- 
rently preferred embodiment, the data consolidator 450 
creates an Extensible Markup Language (XML) representa- 
tion of the additional information which is stored in the 
repository 460. Also, when information from the BAI file is 
retrieved from the repository 460 for presentation to a 
user, all of the information in the source file (e.g., the BAI 
file), including this additional (extra) information is re- 
assembled for presentation to the user. 

[0067] The other "standard" information from the data files (e.g., 



BAI files) that are processed by the system are stored in 
columns and rows of a database. For example, each of the 
standard categories of information in a BAI file is stored in 
a particular column of the database. The additional XML 
mechanism is provided to deal with additional, custom in- 
formation that financial institutions frequently include in 
BAI files. 

[0068] The data consolidator 450 also provides for retrieval of 
information from the repository 460 for presentation to 
users in a manner that enables the users to navigate (e.g., 
page through) the information. This is particularly impor- 
tant as in many cases large volumes of transactions are 
posted to accounts (e.g., corporate bank accounts). In or- 
der to provide information in a format that users can un- 
derstand and deal with, the data consolidator 450 must 
provide for appropriately processing the information be- 
fore it is placed into the repository 460. 

[0069] The methodology of the present invention provides for 
ordering the transaction information and assigning a 
transaction number (or sequence number) to each trans- 
action before the transaction information is stored in the 
repository 460. More particularly, as account information 
is extracted from a BAI (or other) file, the information is 



assigned a sequence number (unique identifier) for the 
purpose of paging this information to the user in man- 
ageable groups or "chunks" of information (e.g., pages). 
Currently, information is sequenced per account and per 
type of information. For example, sequence numbers for 
account transactions on account 1111 are independent 
from account transactions on account 2222. Also, se- 
quence numbers for lockbox transactions on account 
1111 are independent from account transactions on ac- 
count 1111. This allows the present invention to effi- 
ciently extract "pages" of information based on a range of 
sequence numbers for any particular account and type of 
information. The present invention currently provides for 
two alternative paging schemes that can be selected by an 
organization implementing the solution (e.g., a bank) de- 
pending on its environment and requirements. The two 
paging schemes are referred to as "consecutive" and "date- 
based" paging and are described in more detail below. 
The format of the sequence numbers that are assigned are 
based on which type of paging scheme the customer has 
selected. Generally, the "consecutive" scheme provides for 
assigning consecutive sequence numbers, while the "date- 
based" scheme provides for sequence numbers that in- 



elude calendar date information and can accommodate 
gaps in sequencing. 

[0070] By ordering the transaction information and assigning a 
transaction number, the information may be retrieved and 
presented to users (e.g., corporate customers of the bank 
implementing the solution) in pages which represent 
manageable "chunks" of the information. For example, a 
page displayed in the user interface may display a total of 
ten transactions. When the user requests information, the 
transaction number enables the first ten transactions to 
be displayed. The user may then review the next ten 
transactions by selecting a "next" button or the like in the 
user interface. This is considerably more user-friendly 
than presenting a huge list containing hundreds or thou- 
sands of transactions. 

[0071] The live (user-accessible) system 470 typically contains 
the most recent information relating to particular ac- 
counts. As shown at Fig. 4, information is retrieved from 
the live (user-accessible) system 470 and stored in the 
repository 460 using the same APIs on the data consol- 
idator 450 as described above for the BAI or other data 
files which are processed by the file importer 420 and file 
adapter(s) 430. In this fashion "live" data from bank's live 



(user-accessible) system 470 is consolidated with external 
data and stored in the repository 460. However, in this 
case, the data from the live system 470 goes straight to 
the data consolidator 450 and is not processed by an 
adapter (e.g., BAI adapter 430). Data from the live system 
may also be converted into a Java representation, or the 
data may already be in the appropriate format. 
[0072] As a result of the above operations, the repository 460 in- 
cludes a mixture of data from the processed data files 
445 (e.g., data files received from external sources that 
were processed in accordance with an established sched- 
ule) and data obtained from the live, user-accessible sys- 
tem 470. Assume, for example, that a bank receives a set 
of BAI files once per day and processes these files each 
day at midnight. During a particular day, a user (i.e., bank 
account holder) may request account data for a particular 
account 1234. In response, the reporting module 480 may 
obtain current data from the live system 470 and use the 
data consolidator 450 to add the live data into the data 
consolidator's repository 460. The combined information 
from the live system and previously received data files re- 
lating to the particular account 1234 may then be dis- 
played to the user in response to his or her request. The 



user may then issue a bill payment from this account at 2 
pm in the afternoon of that same day. The data consolida- 
tor will update the account information to reflect the bill 
payment (based on information about the bill payment in 
the live system 470). That evening at midnight a new set 
of BAI files is received and processed, including a BAI file 
containing information relating to account 1234. The in- 
formation in this BAI file may duplicate the information 
that came from the live system (e.g., because the BAI file 
includes a record of activity over the past 24 hours on ac- 
count 1234). For example, the BAI file may include infor- 
mation reflecting the bill payment made from the account 
at 2 pm. When the system of the present invention pro- 
cesses data files (e.g., BAI files), the system will automati- 
cally purge any corresponding information in the reposi- 
tory which is marked as live from the user-accessible sys- 
tem. In this example, the bill payment record from the live 
system will be deleted as it is duplicated in the BAI file. 
[0073] The online data view module 490 provides a user interface 
which provides users of the solution with an online view of 
the consolidated account information (e.g., transactions 
on the account such as the above-described bill payment) 
created and stored in the data consolidator repository. 



The online data view module represents the Web-based 
layer of the solution, which includes JSP pages and other 
components to provide a user with a view of banking/ac- 
count information. The reporting module 480 provides 
the infrastructure that supports the online data view mod- 
ule 490. The reporting module 480 also provides users 
with the ability to generate reports. For example, the user 
may request reports concerning account balance details 
for a particular day, week, month, or other period. The re- 
porting module 480 interacts with the data consolidator 
450 to obtain the appropriate information and respond to 
the request. The data that is retrieved is then presented to 
the user by the reporting module 480 and/or the online 
data view module 490. The paging and navigation support 
provided by the invention for presenting information to 
users will next be described in more detail. 
Paging and navigation support 

[0074] a complication in providing users with the ability to navi- 
gate or "page-through" banking/account information pre- 
sented through the data consolidator is that, as previously 
noted, in certain instances information extracted from a 
file (e.g., a BAI file) is in error and the BAI file must be "un- 
done" to correct the error. For example, a federal bank or 



another bank that is sending information may make a 
mistake in information included in a BAI file that is re- 
ceived and processed by the system of the present inven- 
tion. Accordingly, the system of the present invention 
takes into account the fact that one or more of these files 
may need to be corrected. 
[0075] As described above, the system and methodology of the 

present invention provides for sequencing information per 
account and per type of information to enable the solution 
to efficiently extract "pages" of information based on a 
range of sequence numbers for any particular account and 
type of information. A file that must be undone may have 
caused the generation of sequence numbers in the middle 
of several ranges of sequence numbers. Accordingly, the 
system of the present invention currently provides both a 
"consecutive" paging scheme and a "date-based" paging 
scheme for addressing the problem of errors in processed 
data files. The solution is configurable so that a financial 
institution (e.g., bank) implementing the solution may se- 
lect from these schemes based on its particular require- 
ments. 

[0076] with the "consecutive" paging scheme, transactions for an 
account or lockbox are numbered consecutively. In other 



words, there are no gaps in the sequence numbers. This 
paging scheme is the most efficient for retrieving a page 
of data as a page can typically be retrieved with a single 
query to the repository (database). 
[0077] The disadvantage of this method is that when an erro- 
neous BAI file needs to be undone, all BAI files that were 
processed after the erroneous file which contain depen- 
dent information also need to be undone. Dependent in- 
formation would be any information for the same ac- 
counts and type of information contained in the file. For 
example, if file 1 contained account transactions for ac- 
count 1111 and file 2 contained account transactions for 
account 1111, then file 2 contains dependent information. 
However, if file 1 contained account transactions for ac- 
count 1111 and file 2 contained lockbox transactions for 
account 1111, then file 2 does not contain dependent in- 
formation. Assume that file 1 and 2 both contained ac- 
count transactions for account 1111 (i.e., file 2 was de- 
pendent on file 1) and file 1 was in error. In this case both 
File 1 and File 2 would need to be undone. Typically both 
would be undone, corrected, and then reprocessed. One 
can appreciate that if there are a large number of BAI files 
processed throughout the day, this could require correc- 



tion and reprocessing of a considerable number of files. 
Accordingly, consecutive paging is typically used in bank 
environments in which BAI files (or other data files) rarely 
contain errors and/or in environments which process a 
relatively small number of BAI files. 
[0078] For banks which frequently receive and process erroneous 
BAI files, or banks that process large numbers of data 
files, the file dependencies created by the consecutive 
paging scheme becomes inconvenient. To eliminate de- 
pendencies, and thus allow a single BAI file to be undone 
independently of any other file, the present invention also 
provides a "date-based" paging scheme. This paging 
scheme still numbers transactions per account and per 
type of information, but also numbers transactions within 
a particular day. The sequence number (unique identifier) 
assigned to a transaction comprises the date (e.g., 
20040223) followed by a sequence index (1, 2, 3, etc.). 
This mechanism still provides for ascending sequence 
numbers, but provides for a jump in sequence when the 
date changes. This means that sequence numbers for any 
particular day are not generated from the last sequence 
number from the previous day. There are also a suffi- 
ciently large number of possible sequence numbers within 



a particular day that sequence numbers do not need to be 
consecutive within a day. This allows for leaving gaps in 
the sequencing when a file needs to be undone. In the 
event that a file is redone, the redone file would be in- 
serted at the end of that day since there is no guarantee 
that it would fit into any existing gap created. In the 
presently preferred embodiment, the paging APIs which 
retrieve the "next" or "previous" page of entries in the data 
make multiple queries to the database (i.e., the data con- 
solidator repository) in the event that a gap is encoun- 
tered. Date-based paging has slightly more inefficient re- 
trieval of paged data, but is more convenient with respect 
to undoing erroneous files. 
Detailed operation 

[0079] Example of operations in presenting consolidated financial infor- 
mation 

[0080] pigs. 5A-B comprise a single flowchart illustrating the op- 
erations of the system of the present invention in consoli- 
dating financial information and presenting consolidated 
financial information to a user. The following description 
presents method steps that may be implemented using 
computer-executable instructions, for directing operation 
of a device under processor control. The computer-exe- 



cutable instructions may be stored on a computer-read- 
able medium, such as CD, DVD, flash memory, or the like. 
The computer-executable instructions may also be stored 
as a set of downloadable computer-executable instruc- 
tions, for example, for downloading and installation from 
an Internet location (e.g., Web server). 

[0081] The following discussion will use an example of the con- 
solidation of financial information by a bank based on in- 
formation received from external sources (e.g., one or 
more other banks) with data from the bank's own live (or 
back-end) systems. Although this discussion refers to a 
bank, those skilled in the art will appreciate that the sys- 
tem and methodology could be used by other types of fi- 
nancial institutions, corporations, and other organizations 
wishing to consolidate financial information from different 
sources. Accordingly, this example is for purposes of il- 
lustrating the operations of the present invention and not 
for purposes of limitation. 

[0082] The bank implementing the present invention may peri- 
odically receive data files containing financial information 
and may schedule the processing of these files. At step 
501, the system's scheduler invokes the file importer 
module for processing files (e.g., BAI files) that have been 



received. As described above, the bank may use the sys- 
tem's scheduler to schedule the processing of these data 
files at periodic intervals (e.g., several times per day). The 
scheduler also indicates the type of files (e.g., files of type 
BAI) that are to be processed by the file importer. 

[0083] At step 502, the file importer loads the appropriate file 
adapter for processing the type of files to be processed. 
If, for example, BAI files were received by the bank, the 
file importer loads a BAI file adapter for processing the 
BAI files. The file importer is a file processor which in- 
cludes functionality for locating and processing financial 
institution-supplied files that are resident in the file sys- 
tem (for example, BAI files). Each file type is handled by a 
file adapter. As described above, the file importer is a 
pluggable architecture in that it can be extended to sup- 
port additional file types, including proprietary file types. 

[0084] At step 503, each of the data files is parsed using the file 
adapter that was loaded for processing the files. During 
processing the data files (e.g., BAI files), at step 504 the 
file adapter invokes various application programming in- 
terfaces (APIs) on the data consolidator and assigns a se- 
quence number (unique identifier) to each transaction in 
the data file. As described above, the sequence number 



may be a consecutive sequence number or a date-based 
sequence number. At step 505, an XML representation of 
any additional information (if any) included in the file is 
created as part of this process. At step 506, the processed 
information extracted from the data files (including the 
XML representation, if any) is stored in the data consol- 
idator repository. Currently, in the case of BAI files stan- 
dard information is stored in database tables in the 
repository. The XML representation of any additional (or 
extra) data in the BAI files (if any) is also stored in the 
repository so that this additional information may re- 
trieved and provided in response to user requests for in- 
formation. 

[0085] a user may subsequently request information about a 

particular account. At step 507, the reporting module re- 
ceives a request for account information relating to a par- 
ticular account. At step 508, the reporting module checks 
the live (back-end) system and obtains information relat- 
ing to the account (if any) from the live system that is 
more recent than the information in the repository. This 
information from the live system (if any) is consolidated 
with the information stored in the data consolidator 
repository at step 509. Information in the live system 



which duplicates information already stored in the reposi- 
tory is ignored. However, information not yet reflected in 
the repository is sequenced and added to the repository. 
[0086] At step 510, the account information responsive to the 

user's request is retrieved from the repository. The infor- 
mation is then assembled, formatted, and presented to 
the user in the user interface of the system at step 511. 
The user may then review the information and/or request 
additional information using the user interface. The user 
may, for example, select a "next" button provided in the 
presently preferred embodiment to view another page of 
account data. The core components of the system of the 
present invention and their operations are described in 
greater detail below. 
Data consolidator 

[0087] Gene ral 

[0088] At a high level, the data consolidator provides the means 
to consolidate account information in a database reposi- 
tory and retrieve that information. It also handles record- 
ing of historical data for accounts. An adapter module of 
the data consolidator (DCAdapter) contains the logic to 
store and retrieve information from a database repository. 



It is invoked from a file adapter (e.g., the BAI Adapter) of 
the file importer, a data consolidator service, and also 
from other services (including banking, lockbox, and con- 
trolled disbursement). Requests come into the banking, 
lockbox, and disbursement services of the Corporate 
Banking Solution to retrieve information. The default data 
consolidator services implementation fulfills these re- 
quests by doing the following (this example shows a re- 
quest to get recent transaction information): 

[0089] ca || the back-end system to get any transactions that are 
more recent than the stored data; 

[0090] s tore these new transactions in the data consolidator us- 
ing DCAdapter.addTransactions; and 

[0091] ca || DCAdapter.getRecentTransactions to retrieve stored 
data. 

[0092] The data consolidator implements paging in order to sup- 
port retrieving large data sets. Each transaction/item is 
assigned a sequence number (implemented as transac- 
tionlndex in the Transaction Java Bean). Generally, data 
must be inserted into the data consolidator in the order in 
which it should be viewed. 

[0093] The data consolidator also uses database connection 

pooling. The DCAdapter uses a connection pooling utility 



class to gain access to database connections. 

[0094] Related components 

[0095] | n jts currently preferred embodiment as a component of 
the Corporate Banking Solution, components used in the 
implementation of the data consolidator include an alerts 
engine delivery channel (e.g., used for database cleanup). 
Alerts registered with the alerts engine trigger scheduled 
cleanup of files. A user (e.g., system administrator) may 
set the schedules for cleaning up files using a universal 
alerts management console (e.g., to set timing of clean- 
up and information to be cleaned up). 

[0096] Data consolidator Java beans 

[0097] j n e data consolidator also makes use of two Java Beans 
(components) to support data file (e.g., BAI file) rollback 
capability. An ImportedFile Bean represents the file that 
has been imported using the file importer (Filelmporter) 
as follows: int dataSource (e.g., BAI, etc.); String fileName; 
and Calendar fileDate. An ImportedFiles Bean represents a 
list of ImportedFile objects. 

[0098] All of the Beans stored by the data consolidator's adapter 
extend an ExtendABean class. Any data contained by the 
ExtendABean base class will be stored in XML format in a 



DC_ExtendABeanXML table by calling setExtend- 
ABeanXMLO passing in the XML retrieved from the 
database. When fetching an object from the database the 
ExtendABean data will be restored by calling getExtend- 
ABeanXML(). 

[0099] Every data consolidator table has an ExtendABeanXMLID 
column that contains an index into the DC.ExtendABean 
table. If a Bean does not have any ExtendABean data then 
the value of this column will be set to 0. If a Bean does 
have ExtendABean data then a unique index will be gener- 
ated from the DCLRecordCounter table to be used as a key 
for the DC.ExtendABeanXML table. When storing the XML 
in the DC.ExtendABeanXML table it is currently broken up 
into 2,000 character segments and stored in the XMLSeg- 
ment column. The order of the XML segment is preserved 
by storing the segment number in the XMLSegment num- 
ber column. 

[0100] Data consolidator tasks 

[0101] GetBAIFileListByDate: This task calls into the data consol- 
idator to get a list of files that have been processed for a 
specified date range. 

[0102] GetDependentBAIFiles: This task calls into the data con- 
solidator to get a list of dependent files based on the file 



selected. An ImportedFile Bean should be in session. If the 
task processes successfully, the DependantFileList collec- 
tion object is added to session. 

[0103] SetlmportedFile: This task sets an ImportFile Bean in the 
session named (ImportedFile) based on property set. The 
template must set the collectionlndex by calling the 
setlmportedFilelndexO method. An ImportedFileList Col- 
lection should be in session. If the task processes suc- 
cessfully, the ImportedFile is added to session. 

[0104] UndoBAIBatch: This task calls into the data consolidator to 
remove a File and any specified dependent files. An Im- 
portedFile Bean must be in session via (SetlmportedFile 
Task). Task errors set in this task include ER- 
ROR_IMPORTEDFILE_NOT_FOUND. 

[0 1 05] Data consolidator service 

[0106] The data consolidator service reads its configuration in- 
formation from a dataconsolidator.xml configuration file. 
The file includes settings for the service itself, as well as 
settings for the data consolidator's adapter (DCAdapter). A 
sample configuration file is shown below: 

[0107] i: <XML> 

2: <DCADAPTER> 

3: <JAVA_CLASS>com.ffusion.dataconsolidator. DCAdapter 



</JAVA_CLASS> 
4: <DCADAPTER_SETTINGS> 
5: <DB_PROPERTIES> 
6: <Type>DB2</Type> 

7: <DefaultConnections>10</DefaultConnections> 

8: <MaxConnections>30</MaxConnections> 

9: <User>db2instl</User> 

10: <Password>db2instl</Password> 

11: <lnitNow>true</lnitNow> 

12: <PoolType>FFI</PoolType> 

13: <ConnectionType>DB2:NET</ConnectionType> 

14: <Server> 10.25. 147.23</Server> 

15: <DBName>efsold</DBName> 

16: <Port>6789</Port> 

17: <PAGESIZE>40</PAGESIZE> 

18: < / DCADAPTER_SETTI NGS> 

19: </DCADAPTER> 

20: </XML> 

[0108] The settings within the DCADAPTER tags are passed to the 
DCAdapter. Any other settings are for the data consolida- 
tor service itself. 

[0109] The following is a brief description of the data consolida- 
tor service API methods: 



[ono] API: initialize 

Syntax: public void initialize() throws DCException 

[0112] Description: Initialize the data consolidator service using 

the DCADAPTER settings in dataconsolidator.xml. 
[0113] API: cleanup 

[0114] Syntax: public cleanup( String type, int agelnDays, 
Hashmap extra ) throws DCException 

[0115] Description: Removes all information of the specified type 
that is older than the specified number of days. Valid 
types are: All, Account histories, Account summaries, Ac- 
count transactions, Lockbox summaries, Lockbox transac- 
tions, Lockbox credit items, Disbursement summaries, 
Disbursement transactions. 

[0116] API: getAccountReportData 

[° 1 1 y ] Syntax: public com. ffusion. reporting. IReportResult getAc- 
countReportData(ReportCriteria criteria, java.util.HashMap 
extra) throws DCException 

[0118] Description: Gets the report data matching the specified 
report criteria. 

[0119] API: getlmportedFileList 

[0120] Syntax: public ImportedFiles getlmportedFileList(int data- 



Source, java.util. Calendar startDate, java.util. Calendar 
endDate, java.util.HashMap extra) throws DCException 

[0121] Description: Gets the list of files that were imported within 
the given time range. The data consolidator consolidates 
account data from various sources. The data consolidator 
schema also stores the data source and names of the files. 
This function retrieves the list of files that were imported 
in a given time range, specified by start and end dates. If 
the start date and end date are not specified, all files are 
returned. If a start date is not specified, all files up to the 
end date are returned. 

[0122] API: getDependentFiles 

[0123] Syntax: public ImportedFiles getDependent- 

Files(lmportedFile file, java.util.HashMap extra) throws 
DCException 

[0124] Description: Get the list of files that are dependent on a 
given file. The files that are imported after the given file 
create a possible dependency chain. The data consolidator 
provides a paging mechanism to simplify viewing large 
numbers of transactions. In order to achieve effective 
paging, the Data consolidator keeps the transaction index 
associated with each transaction per account and per type 
of information. The index must be in a certain order to 



achieve this. If an error is detected in a loaded file and the 
file needs to be unloaded, one must unload all the files 
that depend on the file to be unloaded. The function will 
identify dependent files and return files that have depen- 
dencies on the specified file. 
[0125] API: undoFile 

[0126] Syntax: public undoFile(lmportedFile file, ImportedFiles 

dependentFiles, java.util.HashMap extra) throws DCExcep- 
tion 

[0127] Description: Removes all the data that was loaded as part 
of a given file and all the dependent files as well. See also 
getDependentFiles, above. 

[0 1 28] Data consolidator adapter 

[0129] As described above, the data consolidator adapter con- 
tains the logic to store and retrieve information from a 
database repository. For any method that modifies the 
data consolidator repository, a database connection must 
be passed into the method. This allows multiple modifica- 
tion methods to be called as part of a single transaction. 
The methods getDBConnection and releaseDBConnection 
are used to retrieve a database connection for use with 
modification methods, and to release the connection once 



done, respectively. A typical transaction using the 

DCAdapter APIs might look like the following: 
[0130] i; Connection connection; 

2: Connection = DCAdapter.getConnection(); 

3: DCAdapter.addAccounts( connection ); 

4: DCAdapter.addTransactions( connection ); 

5: DCAdapter.com mit( connection ); 

6: DCAdapter.releaseConnection( connection ); 
[0131] The data consolidator adapter (DCAdapter) conforms to 

the following interface: 
[0132] i; package com.ffusion.dataconsolidator.adapter; 

2: public class DCAdapter { 

3: /** 

4: Method for initial configuration. This method initializes 
the Data 

Consolidator. This 

5: must be called before any other Data Consolidator met 
hods. 

6: */ 

7: public static void initialize( HashMap settings ) 
8: throws DCException 
[0133] Database Operations 

[0134] 1; /** 



2: Retrieves a database connection object from the pool. 
3: @returns: a Connection for use with other DC Adapter 
methods 

4: */ 

5: public static Connection getDBConnection() 
6: throws DCException 

7: 

8: /** 

9: Returns a database connection object to the pool. 
10: @param connection: database connection object 
11: */ 

12: public static void releaseDBConnection( Connection co 
nnection ) 

13: throws DCException 
14: 

15: /** 

16: Commit changes made to the database. 

17: @param connection: database connection object 

18: */ 

19: public static void commit( Connection connection ) 

20: throws DCException 

21: 

22" J** 



23: Rollback changes made to the database. 

24: @param connection: database connection object 

25: */ 

26: public static void rollback( Connection connection ) 
27: throws DCException 
[0135] Cleanup Operations 

[0136] 1; /** 

2: Removes all information in the database older than th 
e specified 
age in days 

3: @param type: type of information to clean up 

4: @param agelnDays: age in days of the information to 

clean up 

5:*/ 

6: public static void cleanup( String type, int agelnDays, H 

ashmap 

extra ) 

7: throws DCException 

8: 

9: /** 

10: Removes all information from a particular data sourc 
e 

11: @param dataSource: the source of the data (for exam 



pie, l = live, 
2 = BAI) 

12: @param connection: database connection object 
13: */ 

14: public static void cleanupDataSource( int dataSource, 
Connection 

connection, Hashmap extra ) 
15: throws DCException 
16: 

17: /* 

18: Removes all information from a particular BAI file 

19: @param BAIFileldentifier: the BAI filename 

20: @param connection: database connection object 

21: @param extra: HashMap containing information (may 

be null) 

22: */ 

23: public static void cleanupBAIFileldentifier( String 
BAIFileldentifier, Connection connection, HashMap extra ) 
24: throws DCException 
[0137] Operations on Accounts 

[0138] 1; /** 

2: Adds an account to the repository. 
3: @param account: account to be added 



4: @param connection: database connection object 

5: */ 

6: public static void addAccount( com. ffusion. beans. accou 

nts.Account 

account, 

7: Connection connection, Hashmap extra 

) 

8: throws DCException 

9: 

10: /** 

11: Checks if an account exists in the repository 
12: @param account: account to check for existence 
13: @param connection: database connection object 
14: @return: true if the account exists, and false otherwi 
se 

15: */ 

16: public static boolean accountExists( 

com. ffusion. beans. accounts.Account account, 

17: Connection connection, Hashmap 

extra ) 

18: throws DCException 
19: 

20: /** 



21: Retrieve account information for a specified account 

22: @param account: account to retrieve 

23: @return a fully populated Account bean for the accoun 

t 

24: */ 

25: public static com. ffusion. beans. accounts.Account getA 
ccount( 

26: com.ffusion. beans. accounts.Accoun 

t 

account, 

27: Hashmap extra ) 

28: throws DCException 

29: 

30: /** 

31: Updates an account in the repository. 

32: @param account: the account to be updated 

33: @param connection: database connection object 

34: */ 

35: public static void updateAccount( com. ffusion. beans. a 

ccounts.Account 

account, 

36: Connection connection, Hashmap ex 

tra ) 



37: throws DCException 

38: 

39: /** 

40: Deletes an account from the repository 
41: @param account: the account to be updated 
42: @param connection: database connection object 

43: */ 

44: public static void deleteAccount 
( com. ffusion. beans. accounts.Account account, 
45: Connection connection, 

46: Hashmap extra ) 

47: throws DCException 
[0139] Operations on Transactions 

[0140] i: /** 

2: Adds transactions into the repository for a specified a 
ccount 

3: @param account: the account for which we want to ad 
d the 

transactions 

4: @param trans: a list of Transaction objects to be adde 
d 

5: @param dataSource: the source of the data 

6: @param connection: Database connection object 



7: */ 

8: public static void addTransactions( 

com. ffusion. beans. accounts.Account account, 

9: com.ffusion. beans. banking.Transacti 

ons 

trans, 

10: int dataSource, 

11: Connection connection, Hashmap e 

xtra ) 

12: throws DCException 
13: 

14: /** 

15: Retrieves a list of transactions for a specified account 
between 

16: a start dateto an end date 

17: @param account: the account for which we want to r 

etrieve 

transactions 

18: @param startDate: the start date of transactions to g 

et or null 

for no start date 

19: @param endDate: the end date of transactions to get 
or null for 



no end date 

20: @return: a list of Transaction beans 

21: */ 

22: public static com. ffusion. beans. banking.Transactions 
getTransactions( 

23: com. ffusion. beans. accounts.Accou 

nt 

account, 

24: Calendar startDate, 

25: Calendar endDate, 

26: Hashmap extra ) 

27: throws DCException 
28: 

29: /** 

30: Retrieves a list of transactions for a specified account 
between 
a start date 

3 1: to an end date, to a maximum of PAGESIZE of them 
32: @param account: the account for which we want to r 
etrieve 
transactions 

33: @param startDate: the start date of transactions to g 
et or null 



for no start date 

34: @param endDate: the end date of transactions to get 
or null for 
no end date 

35: @return: a list of Transaction beans 

36: */ 

37: public static com. ffusion. beans. banking.Transactions 
getPagedTransactions( 

38: com.ffusion. beans. accounts.Acco 

unt 

account, 

39: Calendar startDate, 

40: Calendar endDate, 

41: Hashmap extra ) 

42: throws DCException 
43: 

44: /** 

45: Retrieves the most recent transactions for the specifi 
ed account 

46: @param account: the account for which we want to r 

etrieve the 

transactions 

47: @return: a list of Transaction beans containing the tr 



ansactions 

48: (at most PAGESIZE of them) 

49: */ 

50: public static com. ffusion. beans. banking.Transactions 
getRecentTransactions( 

51: com.ffusion. beans. accounts.Acco 

unt 

account, 

52: Hashmap extra ) 

53: throws DCException 

54: 

55: /** 

56: Retrieves the next batch of PAGESIZE transactions for 
the 

specified account 

57: @param account: the account for which we want to r 

etrieve the 

transactions 

58: @param nextlndex: the next index of information to 
retrieve 

59: @return: a list of Transaction beans containing the tr 

ansactions 

(at most 



60: PAGE_SIZEof them) 

61: */ 

62: public static com. ffusion. beans. banking.Transactions 
getNextTransactions( 

63: com.ffusion. beans. accounts.Acco 

unt 

account, 

64: long nextlndex, 

65: Hashmap extra ) 

66: throws DCException 
67: 

68: /** 

69: Retrieves the previous batch of PAGESIZE transaction 
s for the 

specified account 

70: @param account: the account for which we want to r 

etrieve the 

transactions 

71: @param lastlndex: the last index of information to re 
trieve 

72: @return: a list of Transaction beans containing the tr 
ansactions 

73: (at most PAGE.SIZE of them) 



74: */ 

75: public static com. ffusion. beans. banking.Transactions 
getPreviousTransactions( 

76: com.ffusion. beans. accounts.Acco 

unt 

account, 

77: long lastlndex, 

78: Hashmap extra ) 

79: throws DCException 
80: 

81: /** 

82: Gets the number of Transactions for a specified acc 
ount between 

83: a range of calendar dates. 

84: @param account: the account for which information i 

s being 

requested 

85: @param start The starting date of information to retrie 

ve, or null 

if no start date 

86: @param end The end date of information to retrieve, o 
r null if no 
end date 



87: @param extra Additional information 

88: */ 

89: public int getNumTransactions( com. ffusion. beans. acc 

ounts.Account 

account, 

90: Calendar start, 
91: Calendar end, 
92: Hashmap extra ) 
93: throws DCException; 
94: 
95: /* 

96: Retrieves a list of transactions for a specified 
FixedDepositlnstru- 

ment between a start date to an end date 

97: @param fdi: the instrument for which we want to retri 

eve 

transactions 

98: @param startDate: the start date of transactions to get 
or null for 
no start date 

99: @param endDate: the end date of transactions to get 
or null for no 
end date 



100: @return: a list of Transaction beans 
101: */ 

102: public static com. ffusion. beans. banking.Transactions 
getFDITransactions( 

103: com. ffusion. beans. accounts. FixedDepositlnstrument 
fdi, 

104: Calendar startDate, 
105: Calendar endDate, 
106: HashMap extra) 
107: throws DCException 
[0141] Operations on Account Summary Information 

[0142] I; /** 

2: Adds summary information into the repository for a sp 

ecified 

account 

3: @param account: the account for which summary infor 
mation has 
been supplied 

4: @param info: the summary information to be added 

5: @param dataSource: the source of the data 

6: @param connection: Database connection object 

7:*/ 



8: public static void addSummary( com. ffusion. beans. acco 

unts.Account 

account, 

9: com. ffusion. beans. accounts.AccountSu 

mmary 

info, 

10: int dataSource, 

11: Connection connection, Hashmap extr 

a) 

12: throws DCException 
13: 

14: /** 

15: Retrieve the summary information for a specified acc 
ount within a 
date range 

16: @param account: the account for which we want the 
summary 

17: @param start: the starting date of information to retr 
ieve or 

null if no start date 

18: @param end: the end date of information to retrieve 
or null if no 
end date 



19: */ 

20: public static com. ffusion. beans. accounts.AccountSum 
maries 

getSummary( 

21: com.ffusion. beans. accounts.Acco 

unt 

account ) 

22: Calendar start, Calendar end, 

23: Hashmap extra ) 

24: throws DCException 
25: 

26: /** 

27: Adds extended summary information into the reposit 
ory for a 

specified account 

28: @param account: the account for which summary inf 
ormation has 
been supplied 

29: @param info: the summary information to be added 

30: @param dataSource: the source of the data 

31: @param connection: Database connection object 

32: */ 

33: public static void addExtendedSummary( 



com. ffusion. beans. accounts.Account account, 



34: 



com. ffusion. beans. accounts. ExtendedAcco 



untSummary 
info, 



35: 



int dataSource, 



36: 



Connection connection, Hashmap extr 



a) 

37: throws DCException 

38: 

39: /** 

40: Retrieve the extended summary information for a spe 
cified account 
within a date range 

41: @param account: the account for which we want the 
summary 

42: @param start: the starting date of information to retr 
ieve or 

null if no start date 

43: @param end: the end date of information to retrieve 
or null if 
no end date 

44: */ 

45: public static com. ffusion. beans. accounts. ExtendedAcc 



ountSummaries 
getExtendedSummary( 

46: com.ffusion. beans. accounts.Acco 

unt 

account, 

47: Calendar start, Calendar end, 

48: Hashmap extra ) 

49: throws DCException 
[0143] Operations on Account History 

[0144] J; /** 

2: Record account history for a particular day 

3: 

4: @param account: the account for which history is to b 
e stored 

5: @param history: the account history information 
6: @param dataSource: the source of the data 
7: @param connection: the database connection 
8: 

9: */ 

10: public static void addHistory( com.ffusion. beans. accou 
nt.Account, 

11: com.ffusion. beans. account.AccountHis 

tory 



history, 

12: int dataSource, 

13: Connection connection, 

14: Hashmap extra ) 

15: throws DCException 

16: 

17: /** 

18: Retrieve a list of account history information within a 
specified 
date range 
19: 

20: @param account: the account for which history is to 
be retrieved 

21: @param start: the starting date of information to retr 
ieve or 

null if no start date 

22: @param end: the end date of transactions to retrieve 
or null if 
no end date 

23: 

24: @return: a list of AccountHistory beans 

25: */ 

26: public static AccountHistories getHistory( 



com. ffusion. beans. accounts.Account account, 



27: 



Calendar start, Calendar end, 



28 



Hashmap extra ) 



29: throws DCException 
[0145] Operations on Lockbox Summaries 



[0146] 1; /■ 



'** 



2: Adds summary information into the repository for a sp 
ecified lockbox 

3: @param summary: the summary information to be ad 
ded 

4: @param dataSource: the source of the data 

5: @param connection: database connection object 

6:*/ 

7: public static void addl_ockboxSummary( 
8: 

com. ffusion. beans. lockbox.LockboxSummary summary, 

9: int dataSource, 

10: Connection connection, 

11: Hashmap extra ) 

12: throws DCException 

13: 

14: /** 

15: Retrieve the summary information for a specified loc 



kbox for 
a date range 

16: @param lockbox: the lockbox for which we want the 
summaries 

17: @param startDate: the start date of summaries to get 
or null if 
no end date 

18: @param endDate: the end date of summaries to get 
or null if no 
end date 

19: */ 

20: public static LockboxSummaries getLockboxSummarie 

s( 

21: 

com. ffusion. beans. lockbox.LockboxAccount lockbox, 
22: Calendar startDate, Calendar 

endDate, 

23: Hashmap extra ) 

24: throws DCException 
[0147] Operations on Lockbox Transactions 

[0148] I; /** 

2: Adds transactions into the repository for a specified lo 
ckbox 



3: @param lockbox: the lockbox for which we informatio 

n has been 

supplied 

4: @param trans: a list of LockboxTransaction objects to 
be added 

5: @param dataSource: the source of the data 

6: @param connection: Database connection object 

7:*/ 

8: public static void addl_ockboxTransactions( 

9: com. ffusion. beans. lockbox. LockboxAccou 

nt 

lockbox, 

10: com. ffusion. beans. lockbox. LockboxTran 

sactions 

trans, 

11: int dataSource, 

12: Connection connection, Hashmap extra ) 

13: throws DCException 

14: 

15: /** 

16: Retrieves a list of transactions for a specified lockbox 
between a 

17: start date to an end date 



18: @param lockbox: the lockbox for which we want the 
transactions 

19: @param startDate: the start date of transactions to g 

et or null 

if no start date 

20: @param endDate: the end date of transactions to get 
or null if no 
end date 

21: @return: a list of LockboxTransaction beans 

22: */ 

23: public static com.ffusion. beans. lockbox. LockboxTrans 
actions 

getl_ockboxTransactions( 

24: com.ffusion. beans. lockbox. LockboxAcco 

unt 

lockbox, 

25: Calendar startDate, 

26: Calendar endDate, 

27: Hashmap extra ) 

28: throws DCException 

29: 

30: /** 

31: Retrieves a list of transactions for a specified lockbox 



between a 

32: start date to an end date, to a maximum of PAGESIZE 
of them 

33: @param lockbox: the lockbox for which we want the 
transactions 

34: @param startDate: the start date of transactions to g 

et or null 

if no start date 

35: @param endDate: the end date of transactions to get 
or null if no 
end date 

36: @return: a list of LockboxTransaction beans 

37: */ 

38: public static com.ffusion. beans. lockbox. LockboxTrans 
actions 

39: getPagedl_ockboxTransactions( 

40: com.ffusion. beans. lockbox. LockboxAcco 

unt 

lockbox, 

41: Calendar startDate, 

42: Calendar endDate, 

43: Hashmap extra ) 

44: throws DCException 



45: 

46: /** 

47: Retrieves the most recent transactions for the specifi 
ed lockbox 

48: @param lockbox: the lockbox for which we want the 
transactions 

49: @return: a list of LockboxTransaction beans containi 
ng the 

50: transactions (at most PAGESIZE of them) 
51: */ 

52: public static com.ffusion. beans. lockbox. LockboxTrans 
actions 

getRecentl_ockboxTransactions( 

53: com.ffusion. beans. lockbox. LockboxAcco 

unt 

lockbox, 

54: Hashmap extra ) 

55: throws DCException 

56: 

57: /** 

58: Retrieves the next batch of PAGESIZE transactions for t 

he specified 

lockbox 



59: @param lockbox: the lockbox for which we want the 
transactions 

60: @param nextlndex: the next index of information to 
retrieve 

61: @return: a list of LockboxTransaction beans containi 
ng the 

62: transactions (at most PACE_SIZE of them) 

63: */ 

64: public static com.ffusion. beans. lockbox. LockboxTrans 
actions 

getNextl_ockboxTransactions( 

65: com.ffusion. beans. lockbox. LockboxAcco 

unt 

lockbox, 

66: long nextlndex, 

67: Hashmap extra ) 

68: throws DCException 
69: 

70: /** 

71: Retrieves the previous batch of PAGESIZE transaction 
s for the 

72: specified lockbox 

73: @param lockbox: the lockbox for which we want to r 



etrieve 
transactions 

74: @param lastlndex: the last index of information to re 
trieve 

75: @return: a list of LockboxTransaction beans containi 
ng the 

transactions (at 

76: most PAGE.SIZE of them) 

77: */ 

78: public static com.ffusion. beans. lockbox. LockboxTrans 
actions 

getPreviousLockboxTransactions( 

79: com.ffusion. beans. lockbox. LockboxAcco 

unt 

lockbox, 

80: long lastlndex, 

81: Hashmap extra ) 

82: throws DCException 
[0149] Operations on Lockbox Credit Items 

[0150] 1; /** 

2: Adds credit items into the repository for a specified lo 
ckbox 

3: @param lockbox: the lockbox for which we informatio 



n has been 
supplied 

4: @param items: a list of LockboxCreditltem objects to 
be added 

5: @param dataSource: the source of the data 

6: @param connection: Database connection object 

7:*/ 

8: public static void addl_ockboxCreditltems( 

9: com. ffusion. beans. lockbox. LockboxAccou 

nt 

lockbox, 

10: com. ffusion. beans. lockbox. LockboxCred 

itltems 

items, 

11: int dataSource, 

12: Connection connection, Hashmap extra ) 

13: throws DCException 

14: 

15: /** 

16: Retrieves a list of credit items for a specified lockbox 
between a 

17: start date to an end date 

18: @param lockbox: the lockbox for which we want to r 



etrieve credit 
items 

19: @param startDate: the start date of items to get or n 
ull for no 
start date 

20: @param endDate: the end date of items to get or null 
for no end 
date 

21: @return: a list of LockboxCreditltem beans 

22: */ 

23: public static com. ffusion. beans. lockbox. LockboxCredi 
tltems 

getl_ockboxCreditltems( 

24: com. ffusion. beans. lockbox. LockboxAcco 

unt 

lockbox, 

25: Calendar startDate, 

26: Calendar endDate, 

27: Hashmap extra ) 

28: throws DCException 

29: 

30: /** 

31: Retrieves a list of credit items for a specified lockbox 



between a 

32: start date to an end date, to a maximum of PAGESIZE 
of them 

33: @param lockbox: the lockbox for which we want to r 

etrieve credit 

items 

34: @param startDate: the start date of items to get or n 
ull for no 
start date 

35: @param endDate: the end date of items to get or null 
for no end 
date 

36: @return: a list of LockboxCreditltem beans 

37: */ 

38: public static com. ffusion. beans. lockbox. LockboxCredi 
tltems 

getPagedl_ockboxCreditltems( 

39: com. ffusion. beans. lockbox. LockboxAcco 

unt 

lockbox, 

40: Calendar startDate, 

41: Calendar endDate, 

42: Hashmap extra ) 



43: throws DCException 
44: 

45: /** 

46: Retrieves the most recent credit items for the specifi 
ed lockbox 

47: @param lockbox: the lockbox for which we want to r 

etrieve credit 

items 

48: @return: a list of LockboxCreditltem beans containin 
g the items 

49: at most PAGESIZE of them) 

50: */ 

51: public static com. ffusion. beans. lockbox. LockboxCredi 
tltems 

getRecentl_ockboxCreditltems( 

52: com.ffusion. beans. lockbox. LockboxAcco 

unt 

lockbox, 

53: Hashmap extra ) 

54: throws DCException 

55: 

56: /** 

57: Retrieves the next batch of PAGESIZE credit items for t 



he specified 
lockbox 

58: @param lockbox: the lockbox for which we want the 
credit items 

59: @param nextlndex: the next index of information to 
retrieve 

60: @return: a list of LockboxCreditltem beans containin 
g the items 

61: (at most PAGE.SIZE of them) 

62: */ 

63: public static com. ffusion. beans. lockbox. LockboxCredi 
tltems 

getNextLockboxCreditltems( 

64: com. ffusion. beans. lockbox. LockboxAcco 

unt 

lockbox, 

65: long nextlndex, 

66: Hashmap extra ) 

67: throws DCException 
68: 

69: /** 

70: Retrieves the previous batch of PAGESIZE credit items 
for the 



71: specified lockbox 

72: @param lockbox: the lockbox for which we want to r 

etrieve credit 

items 

73: @param lastlndex: the last index of information to re 
trieve 

74: @return: a list of LockboxCreditltem beans containin 
g the items 

75: at most PAGE.SIZE of them) 

76: */ 

77: public static com. ffusion. beans. lockbox. LockboxCredi 
tltems 

getPreviousl_ockboxCreditltems( 

78: com. ffusion. beans. lockbox. LockboxAcco 

unt 

lockbox, 

79: long lastlndex, 

80: Hashmap extra ) 

81: throws DCException 
[0151] Operations on Disbursement Summaries 

[0152] I; /** 

2: Adds disbursement summary information into the rep 
ository for a 



specified account 

3: @param summary: the summary information to be ad 
ded 

4: @param dataSource: the source of the data 

5: @param connection: database connection object 

6:*/ 

7: public static void addDisbursementSummary( 
8: 

com. ffusion. beans. disbursement. DisbursementSummary s 
ummary, 

9: int dataSource, 

10: Connection connection, 

11: Hashmap extra ) 

12: throws DCException 

13: 

14: /** 

15: Retrieve the summary information for a specified dis 
bursement for 
a date range 

16: @param account: the disbursement for which we wan 
t the summaries 

17: @param startDate: the start date of summaries to get 
or null if 



no start date 

18: @param endDate: the end date of summaries to get 
or null if no 
start date 

19: */ 

20: public static DisbursementSummaries getDisbursemen 

tSummaries( 

21: 

com. ffusion. beans. disbursement. DisbursementAccount ac 
count, 

22: Calendar startDate, Calendar endDa 

te, 

23: Hashmap extra ) 

24: throws DCException 
[0153] Operations on Disbursement Transactions 

[0154] I; /** 

2: Adds transactions into the repository for a specified 
disbursement account 

3: @param account: the account for which we want to ad 
d the 

transactions 

4: @param trans: a list of DisbursementTransaction obje 
cts to be 



added 

5: @param dataSource: the source of the data 

6: @param connection: Database connection object 

7:*/ 

8: public static void addDisbursementTransactions( 

9: 

com. ffusion. beans. disbursement. DisbursementAccount ac 

count, 

10: 

com. ffusion. beans, disbursement. DisbursementTransactio 
ns trans, 

11: int dataSource, 

12: Connection connection, Hashmap extra ) 

13: throws DCException 

14: 

15: /** 

16: Retrieves a list of transactions for a specified disburs 
ement 

account between a 

17: start date to an end date 

18: @param account: the disbursement account for whic 
h we want to 
retrieve transactions 



19: @param startDate: the start date of transactions to g 

et or null 

if no start date 

20: @param endDate: the end date of transactions to get 
or null if no 
end date 

21: @return: a list of DisbursementTransaction beans 

22: */ 

23: public static 

com. ffusion. beans. disbursement. DisbursementTransactio 
ns 

getDisbursementTransactions( 
24: 

com. ffusion. beans. disbursement. DisbursementAccount ac 
count, 

25: Calendar startDate, 

26: Calendar endDate, 

27: Hashmap extra ) 

28: throws DCException 

29: 

30: /** 

31: Retrieves a list of transactions for a specified disburs 
ement 



account between a 

32: start date to an end date, to a maximum of PAGESIZE 
of them 

33: @param account: the disbursement account for whic 
h we want to 
retrieve transactions 

34: @param startDate: the start date of transactions to g 

et or null 

if no start date 

35: @param endDate: the end date of transactions to get 
or null if no 
end date 

36: @return: a list of DisbursementTransaction beans 

37: */ 

38: public static 

com. ffusion. beans, disbursement. DisbursementTransactio 
ns 

39: getPagedDisbursementTransactions( 
40: 

com. ffusion. beans. disbursement. DisbursementAccount ac 
count, 

41: Calendar startDate, 

42: Calendar endDate, 



43: Hashmap extra ) 

44: throws DCException 

45: 

46: /** 

47: Retrieves the most recent transactions for the specifi 
ed 

disbursement account 

48: @param account: the disbursement account for whic 
h we want to 
retrieve transactions 

49: @return: a list of DisbursementTransaction beans co 
ntaining the 

50: transactions (at most PAGESIZE of them) 

51: */ 

52: public static 

com. ffusion. beans. disbursement. DisbursementTransactio 
ns 

getRecentDisbursementTransactions( 
53: 

com. ffusion. beans. disbursement. DisbursementAccount ac 
count, 

54: Hashmap extra ) 

55: throws DCException 



56: 

57: /** 

58: Retrieves the next batch of PAGESIZE transactions for 
the 

59: specified disbursement account 

60: @param account: the disbursement account for whic 

h we want to 

retrieve transactions 

61: @param nextlndex: the next index of information to 
retrieve 

62: @return: a list of DisbursementTransaction beans co 

ntaining the 

transactions (at 

63: most PAGE.SIZE of them) 

64: */ 

65: public static 

com. ffusion. beans, disbursement. DisbursementTransactio 
ns 

getNextDisbursementTransactions( 
66: 

com. ffusion. beans. disbursement. DisbursementAccount ac 
count, 

67: long nextlndex, 



68: Hashmap extra ) 

69: throws DCException 

70: 

71: /** 

72: Retrieves the previous batch of PAGESIZE transaction 

s for the 

specified 

73: disbursement account 

74: @param account: the disbursement account for whic 
h we want to 
retrieve transactions 

75: @param lastlndex: the last index of information to re 
trieve 

76: @return: a list of DisbursementTransaction beans co 
ntaining the 

77: transactions (at most PAGE.SIZE of them) 

78: */ 

79: public static 

com. ffusion. beans, disbursement. DisbursementTransactio 
ns 

getPreviousDisbursementTransactions( 
80: 

com. ffusion. beans. disbursement. DisbursementAccount ac 



count, 

81: long lastlndex, 

82: Hashmap extra ) 

83: throws DCException 
[0155] Reporting 

[0156] 1; /** 

2: Get the data for a specified account report. 
3: @param criteria: the criteria of the report 

4: */ 

5: public IReportResult getAccountReportData( ReportCrite 
ria criteria, 

6: HashMap extra ) 

7: throws DCException 

8: 

9: /** 

10: Get the data for a specified disbursement report. 
11: @param criteria: the criteria of the report 

12: */ 

13: public IReportResult getDisbursementReportData( Rep 

ortCriteria 

criteria, 

14: HashMap extra ) 

15: throws DCException 



16: 

17: /** 

18: Get the data for a specified lockbox report. 
19: @param criteria: the criteria of the report 

20: */ 

21: public IReportResult getl_ockboxReportData( ReportCri 
teria criteria, 

22: HashMap extra ) 

23: throws DCException 

24:} 

[0157] Operations on Fixed Deposit Instruments 
[0158] 1; /** 

2: Adds an instrument into the repository 

3: @param incominglnstrument: the instrument that we w 

ant to add 

4: @param dataSource: the source of the data 

5: @param connection: Database connection object 

6:*/ 
7: 

8: public static void addFixedDepositlnstrument( 

9: com. ffusion. beans. accounts. FixedDepositlnstrument 

incominglnstrument, 

10: int dataSource, 



11: Connection connection, 
12: HashMap extra ) 
13: throws DCException 
14: 
15: 

16: /** 

17: Retrieves a list of instruments for a account between 
a start 

date and an end date 

18: @param account: the account for which we want to r 

etrieve 

instruments 

19: @param startDate: the start date of transactions to g 

et or null 

if no start date 

20: @param endDate: the end date of transactions to get 
or null if no 
end date 

21: @return: a list of FixedDepositlnstrument beans 

22: */ 
23: 

24: public static FixedDepositlnstruments getFixedDeposit 
lnstruments( 



25: com. ffusion. beans. accounts.Account account, 
26: Calendar startDate, 
27: Calendar endDate, 
28: HashMap extra ) 
29: throws DCException 
File adapter 

[0159] The file adapter parses data files and stores the contents 
into the data consolidator. For example, a BAI file adapter 
parses BAI files and stores the contents into the data con- 
solidator. The following discussion describes a BAI file 
adapter provided in the currently preferred embodiment, 
which is provided as a Java class that conforms to an 
IFileAdapter interface. The current version of the BAI file 
adapter will support group status codes (found in the 02 
Group Header Record) of l=Update only. 

[0160] The public interface of the file adapter is as follows: 

[° 161 ] 1: public interface IFileAdapter { 

2: 

3 ■ /** 

4: Initializes the File Adapter 

5: @param initialize: any settings required for initializat 
ion 



6: */ 

7: public void initialize( HashMap initialize ) 
8: throws FIException; 

9: 

10: /** 

11: Obtain any resources that are required prior to invo 
king 

processFiles 

12: */ 

13: public void open( Hashmap extra ) 

14: throws FIException; 

15: 

16: /** 

17: Release any resources acquired by a call to open 

18: */ 

19: public void close( Hashmap extra ) 

20: throws FIException; 

21: 

22: /** 

23: Imports (and processes) the file specified by 'is' 

24: @param is: an Input Stream for the file to be importe 

d 

25: */ 



26: public void processFile( InputStream is, Hashmap extr 
a) 

27: throws FIException; 

28: } 

[0162] The initialize method would be called only once by the File 
Importer Handler initialization. The open, close, and pro- 
cessFile methods would be called repeatedly. For exam- 
ple, to process a single file, the code would invoke: 

[0163] 0 pen(...) 

[0164] P rocessFile( ... ) 
[0165] c lose(... ) 

[0166] jo process multiple files, the code would invoke: 
[0167] 0 pen(...) 

[0168] f or eacri fj| e {processFile( ... )} 
[0169] c lose(...) 

[0170] The following will briefly describe each of the methods in- 
cluded in the file adapter API: 
[0171] API: initialize 

[0172] Syntax: public void initialize( HashMap initialize ) throws 
FIException 



[0173] Description: Initializes the file adapter so that it is ready 

for use. 
[01 74] API: open 

[0175] Syntax: public void open( Hashmap extra ) throws FIEx- 
ception 

[0176] Description: Prepare the adapter for a series of (possibly 

one) calls to processFile. 
[0177] A p| : close 

[0178] Syntax: public void close( Hashmap extra ) throws FIEx- 
ception 

[0179] Description: Releases the resources obtained by a previ- 
ous call to open. 
[0180] API: processFile 

[0181] Syntax: public void processFile( InputStream is, Hashmap 
extra ) throws FIException 

[0182] Description: Validate and process one BAI file. The file to 
be processed is passed as an InputStream. The file con- 
tents are broken apart and stored in the data consolida- 
tor. 

[0183] semantics: 

[0184] 1. call DCAdapter.getDBConnection to get a database 
connection from the DCAdapter pool. 



[0185] 2. Begin reading the BAI file. The file is processed as it is 
read. The file is not read in one chunk into memory since 
it can be large. 

[0186] 3. For each Account Header found, determine if the ac- 
count requires consolidation. Consolidation occurs only 
for accounts known to the profile database (i.e. registered 
for online services with the Corporate Banking Solution). If 
the account does not require consolidation, then skip all 
fields until the end of the Account Trailer. 

[0187] 4_ |f t he account requires consolidation, read the records 
and extract status, summary, and detail information into 
the appropriate tables. 

[° 188 ] 5. Repeat steps 3-8 for each Croup found in the BAI File. 

[0189] 6. if the file is parsed completely without errors, use 

DCAdapter. commit to commit the BAI file information to 
the Data Consolidator. 

[0190] 7. Release the DB Connection by calling 
DCAdapter. releaseConnection. 

[° 191 ] 8. If an error occurred, use DCAdapter.rollback to rollback 
the information and throw the Exception. 

[0192] Exceptions (Core API Exceptions, DCExceptions and FIEx- 
ceptions): For all exceptions thrown from within the data 
consolidator service there is a DCException class. All er- 



rors that are thrown from the service have an error code 
defined within the class. These exceptions are caught by 
the Core API logic and wrapped in an exception with an 
appropriate error code. The BAI file adapter throws FIEx- 
ceptions. 

[0193] Logging: The data consolidator uses the Java Logging API 
(in the javax.util. logging package) to log information dur- 
ing program execution. 
File importer 

[0194] The file importer is a file processor which locates and 

processes financial institution-supplied files that are al- 
ready resident in the file system (for example, BAI files 
and Positive Pay Issues files). Each file type is handled by a 
file adapter. The file importer is a pluggable architecture 
in that it can be extended to support additional file types, 
including proprietary file types. The role of the file im- 
porter in the processing of files is described below. 

[0195] At scheduled times, the alerts engine (or scheduler) will 
fire alerts to process financial institution-supplied files. 
Alerts can be set to process different file types at different 
times. When the alert fires, a delivery channel registered 
with the alerts engine is invoked. Control passes to the 
processFiles method in the file importer service (public 



void processFiles( String fileType, HashMap extra) throws 
FIException). 

[0196] The file type for scheduled processing may include BAI 

and Positive Pay Issues files. The file type for on-demand 
processing may include SWIFT BIC Directory, SWIFT BIC Di- 
rectory Update, and Federal Reserve Directory Update 
files. The processing that takes place will be dependent on 
the file type. For example, BAI files are imported into the 
data consolidator. Positive Pay Issues files are imported 
into the Positive Pay database. 

[0197] a file importer service creates and initializes the various 
file processing adapters and maintains the mapping from 
file type to adapter instance. The service is also responsi- 
ble for placing uploaded files into the file system and 
managing error and archive directories. The file importer 
service requires several pieces of information for configu- 
ration. See Configuration (fileimporter.xml), below, for 
detailed information. 

[0198] The file importer service API provides the entry points for 
retrieving a list of supported file types that can be up- 
loaded; uploading and processing of a client-uploaded file 
(invoked by the Corporate Banking Solution); scheduled 
processing of financial institution supplied files of a spec- 



ified type (invoked by an Alerts Delivery Channel); cleanup 
of client-uploaded or financial institution supplied files 
(invoked by an alerts delivery channel); and on-demand 
processing of files of a specified type (set up using Busi- 
ness Central). The file importer service does not need to 
be customized in order to support new file types. 
[0199] The following illustrates the interface of the file importer: 



[0200] 1 
2 
3 
4 
5 
6 
7 
8 
9 



public interface Filelmporter { 

I** 

Initializes the File Importer 

*/ 

public void initialize( HashMap settings ) 
throws FIException 



/* 



Get the list of file types the user can upload. 
10: @param user: the SecureUser requesting to upload 
11: */ 

12: public ArrayList getUploadFileTypes( 

com. ffusion. beans. SecureUser user, 

13: Hashmap extra ) 

14: throws FIException 

15: 



16: /** 

17: Uploads and processes a file. 

18: @param user: the SecureUser requesting to upload 

19: @param file: the file contents uploaded in byte array 

format 

20: @parm fileType: the type of file to upload 
21: @parm fileName: the name of the file 

22: */ 

23: public void upload( com.ffusion. beans. SecureUser use 
r, 

byte[] file, 

24: String fileType, String filename, 

25: Hashmap extra ) 

26: throws FIException 

27: 

28: /** 

29: Processes (on a schedule) the contents of files of th 
e 

specified type. 

30: @param fileType: the type of files to process 
31: */ 

32: public void processFiles( String fileType, 
33: Hashmap extra ) 



34: throws FIException 

35: 

36: /** 

37: Removes files (on a schedule) that are considered sta 
le. 

38: @param fileType: the type of files that is to be cleane 
d up 

39: @param status: the status of the files to be cleaned u 
P 

40: @param agelnDays: age of the files to be cleaned up 
41: */ 

42: public void cleanup( String fileType, String status, int 
agelnDays, 

43: Hashmap extra ) 

44: throws FIException 

45:} 

[0201] The following will briefly describe the methods of the file 

importer service API: 
[0202] A p| : initialize 

[0203] Syntax: public void initialize() throws FIException 

[0204] Description: Initialize the file importer. This method is in- 
voked during initialization and reads configuration infor- 



mation from the fileimporter.xml file. Initialization is 
completed prior to any other file importer method being 
called. 

[0205] API: getUploadFileTypes 

[0206] Syntax: public static ArrayList getUploadFileTypes( 

com. ffusion. beans. SecureUser user, Hashmap extra ) 
throws FIException 

[0207] Description: Build a list of file types (Strings) that can be 
uploaded. The system will automatically filter out file 
types for which the user does not have permission. 

[0208] API: upload 

[0209] Syntax: public void upload( com. ffusion. beans. SecureUser 
user, byte[] file, String fileType, String filename, Hashmap 
extra ) throws FIException; 

[0210] Parameters: user: the SecureUser requesting file upload; 
file: the file contents uploaded in byte array format; file- 
Type: the type of file to upload; fileName: the name of the 
file; and extra: any additional information for custom im- 
plementations. 

[021 1] Description: Take the contents of a file (in a byte array) 

and store the data into the file system. Based on the spec- 
ified file type, the appropriate file adapter is called to pro- 



cess the file. Valid file types are listed in the configuration 
file. The uploaded file is given a unique name in the fol- 
lowing format and placed in the process directory config- 
ured for that file type: 
[0212] <USER_NAME>-<DATE>-<TIME>-<FILE_NAME> 

[0213] where: USER.NAME is the name of the user as specified in 
the com. ffusion. beans. SecureUser object supplied in the 
user parameter (any characters that are not valid for a file 
name are replaced by an underscore); DATE is the date the 
file was imported, in the format YYYYMMDD; TIME is the 
time the file was imported, in the format HHMMSS; and 
FILE.NAME is the name of the file as specified in the file- 
Name parameter. 

[0214] For example, suppose the user tbowman uploads three 
ACH files called "myfilel.txt", "myf ile2.txt", and "my- 
file2.txt". Three files will get written (by three separate 
calls to upload) with the following names: 

[0215] tbowman-20020722-080042-myfilel.txt 

[0216] tbowman-20020722-123022-myfile2.txt 

[0217] tbowman-20020722-154516-myfile2.txt 

[0218] The open, processing, and close methods are then in- 
voked in sequence on the file adapter. If processing is 



successful, the file is moved to the archive directory. Oth- 
erwise, the error information is stored in the error direc- 
tory. If the file was copied to the "error" directory, a text 
file containing details of the error is also written to the "er- 
ror" directory. The file has the same name as the moved 
file, but with extension ".err". The format of this file is 
currently as follows: 
[0219] |_j ne i; Date and time of processing (when the error oc- 
curred). 

[0220] |_j ne 2-n: the exception, including stack trace, that caused 

processing to abort. 
[° 221 ] API: processFiles 

[0222] Syntax: public void processFiles( String fileType, Hashmap 
extra ) throws FIException 

[0223] Parameters: filetype: the type of files to process; and ex- 
tra: any additional information for custom implementa- 
tions. 

[0224] Description: This routine is invoked on a schedule-driven 
or on-demand basis, to process files of the specified type 
residing in the file system. The type of processing de- 
pends on the file type. The file adapter "open" method is 
invoked. For each file in the process directory (or a subdi- 
rectory thereof), the file is read and the contents of the 



file are passed to the processFiles method of the file 
adapter. The "close" method of the file adapter is then 
called. Successfully processed files are moved to the 
archive directory. Unsuccessfully processed files are 
copied to the error directory. 

[0225] As files are moved into the "archive" or copied into the "er- 
ror" directory, the subdirectory structure will be preserved 
in the destination directory and subdirectories will be cre- 
ated as needed. For example, if PRO- 
CESS_DIR/foo/bar/baz/ SomeFileName.BAI is processed 
successfully, it will be moved to the 
ARCHIVE_DIR/foo/bar/baz directory. When a file is moved, 
the file will be renamed using the following convention: 

[0226] <ORIGINAL_FILENAME>-<DATE>-<TIME>.<ORICINAL_FIL 
E_EXT> 

[0227] where: ORIGINAL_FILENAME is the stem of the original file 
name (file name without the extension); DATE is the date 
the original file was created, in the format YYYYMMDD; 
TIME is the time the original file was created, in the format 
HHMMSS; and ORIGINAL_FILE_EXT is the extension of the 
original file. If the file was copied to the "error" directory, 
then a text file containing details of the error is also writ- 
ten to the "error" directory. The file has the same name as 



the moved file, but with the extension ".err". 
[0228] API: cleanup 

[0229] Syntax: public void cleanup( String fileType, String status, 
int agelnDays, Hashmap extra ) throws FIException 

[0230] Parameters: fileType: the type of files to be cleaned up; 
status: the status of the files to be cleaned up (process, 
archive, or error); and agelnDays: age of the files to be 
cleaned up. 

[0231] Description: Remove files that are considered to be stale 
(process, error, or archived files). Directories are cleaned 
up recursively. 

[0232] Configuring the file importer service 

[0233] jhe file importer service uses several pieces of informa- 
tion for its configuration. Specifically, it needs information 
to determine to which file adapter it should pass a file of a 
specific type. For each file adapter, the following informa- 
tion is required: 

[0234] FileType - "ACH", "ACH Import", "BAI", "Positive Pay Check 
Record", "Positive Pay Issues", "Account Register Check 
Record", "Custom", and others 

[0235] ProcessDir - directory where files to be processed reside 

[0236] ArchiveDir - directory to which successfully processed 



files are moved 

[0237] ErrorDir - directory to which unsuccessfully processed 
files are copied (and to which error files written) 

[0238] AdapterClass - the Java class that implements the file 
adapter for the file type (can be empty for files that are 
uploaded but do not need additional processing) 

[0239] DisplayForUpload - show this file type as a type that can 
be uploaded by the client. The service will find this infor- 
mation in an XML configuration file called "fileim- 
porter.xml". When the "initialize" method of the service is 
invoked, it will load the configuration file, parse it, and 
initialize the file adapters registered in the file. 

[0240] | n addition, each file adapter may require additional con- 
figuration information specific to that file adapter. For ex- 
ample, the Positive Pay Check Record file adapter requires 
the following Message Broker information: Message set; 
Message name; DatabaseType; UseThinDriver; Machine 
name; Port number; Database name; User ID; and Pass- 
word. 

[0241] Properties specific to a file adapter are enclosed within 
ADAPTERS ETTINGS. A portion of the fileimporter.xml file 
is shown below: 

[0242] i: <XML> 



2: <DB_PROPERTIES> 

3: <DefaultConnections>l</DefaultConnections> 

4: <MaxConnections>30</MaxConnections> 

5: <User>db2instl</User> 

6: <Password>db2instl</Password> 

7 : < PoolTy pe > FFI < / PoolType > 

8: <ConnectionType>DB2:NET</ConnectionType> 

9: <Server>cbdbserver</Server> 

10: <DBName>cbdb</DBName> 

11: <Port>6789</Port> 

12: </DB_PROPERTIES> 

13: <FILEADAPTER> 

14: <FILETYPE>ACH</FILETYPE> 

15: <ENTITLEMENTNAME>ACHBatch</ENTITLEMENTNA 
ME> 

16: <PROCESSDIR>/usr/corporate/ach/process/</PROC 
ESSDIR> 

17: <ARCHIVEDIR>/usr/corporate/ach/archive/</ARCHI 
VEDIR> 

18: <ERRORDIR>/usr/corporate/ach/error/</ERRORDIR 

> 

19: <ADAPTERCLASS>com.ffusion.fileimporter.fileadapte 
rs.ACHAdapter</ 



20: ADAPTERCLASS> 

21: <DISPLAYFORUPLOAD>true</DISPLAYFORUPLOAD> 

2 2 : < ADAPTERS ETTINGS> 

23: < / ADAPTERS ETTINGS> 

24: </FILEADAPTER> 

25: <FILEADAPTER> 

26: <FILETYPE>BAK/FILETYPE> 

27: <PROCESSDIR>/usr/corporate/bai/process/</PROC 
ESSDIR> 

28: <ARCHIVEDIR>/usr/corporate/bai/archive/</ARCHI 
VEDIR> 

29: <ERRORDIR>/usr/corporate/bai/error/</ERRORDIR 
> 

30: <ADAPTERCLASS>com.ffusion.fileimporter.fileadapte 

rs.BAIAdapter</ 

31: ADAPTERCLASS> 

32: <DISPLAYFORUPLOAD>false</DISPLAYFORUPLOAD> 
33: </FILEADAPTER> 
34: <FILEADAPTER> 

35: <FILETYPE> Positive Pay Check Record </FILETYPE> 
36: <ENTITLEMENTNAME> Positive Pay < / ENTITLEM ENTN 
AME> 

37: <PROCESSDIR>/usr/corporate/positivepaycheckreco 



rd/process/</ 
38: PROCESSDIR> 

39: <ARCHIVEDIR>/usr/corporate/positivepaycheckreco 

rd/archive/</ 

40: ARCHIVEDIR> 

41: <ERRORDIR>/usr/corporate/positivepaycheckrecord 
/error/ </ERRORDIR> 

[0243] The ACH file adapter is an example of a file type that can 
be uploaded by the client. The BAI file adapter is an ex- 
ample of a file type that is supplied by the financial insti- 
tution and processed on a schedule. The Positive Pay- 
Check Record file adapter is an example of a file adapter 
that has adapter specific properties (ADAPTERS ETTINGS). 

[0244] i: <ADAPTERCLASS>com.ffusion.fileimporter.fileadapters. 
PPayCheckRecordFile 
2: Adapter</ADAPTERCLASS> 

3: <DISPLAYFORUPLOAD>true</DISPLAYFORUPLOAD> 
4: < ADAPTERS ETTINGS> 
5: <MESSAGEBROKER> 

6: < MESSAG ESET> PositivePayCheckRecord < / MESSAGES 
ET> 

7: < M ESSAG ENAM E> PositivePayCheckRecord < / M ESSAG 
ENAME> 



8: <DBTYPE>DB2:APP</DBTYPE> 

9: <USETHINDRIVER>true</USETHINDRIVER> 

10: <MACHINE>mbdbserver</MACHINE> 

11: <PORTNUM>8888</PORTNUM> 

12: <DBNAME>mbdemo</DBNAME> 

13: <USERID>mbdbuser</USERID> 

14: <PASSWORD>mbdbpasswd</PASSWORD> 

15: < / M ESSAG EBROKER> 

16: </ ADAPTERS ETTINGS> 

17: </FILEADAPTER> 

18: <FILEADAPTER> 

19: <FILETYPE>Custom</FILETYPE> 

20: <ENTITLEMENTNAME>Custom File Upload</ENTITLE 

MENTNAME> 

21: <PROCESSDIR>/usr/corporate/custom/process/</P 
ROCESSDIR> 

22: <ARCHIVEDIR>/usr/corporate/custom/archive/</AR 
CHIVEDIR> 

23: <ERRORDIR>/usr/corporate/custom/error/</ERROR 
DIR> 

24: <ADAPTERCLASS>com.ffusion.fileimporter.fileadapte 

rs.CustomAdapter 

</ADAPTERCLASS> 



25: <DISPLAYFORUPLOAD>false</DISPLAYFORUPLOAD> 

26: < ADAPTERS ETTINGS> 
[0245] The custom file adapter is shown for further detail about 

processing file formats that are specific to a customer. 
[0246] i; <!__ Custom upload file definition for Positive Pay Chec 

k Record — > 

2: <OUTPUTFORMAT> 

3: <NAME>Positive Pay Check Record</NAME> 

4: <FIELDDEFINITIONLIST> 

5: <FIELDDEFINITION> 

6: <NAME>Account Number</NAME> 

7: </FIELDDEFINITION> 

8: <FIELDDEFINITION> 

9: <NAME>Routing Number</NAME> 

10: </FIELDDEFINITION> 

11: <FIELDDEFINITION> 

12: <NAME>Check Number</NAME> 

13: </FIELDDEFINITION> 

14: <FIELDDEFINITION> 

15: <NAME>Check Date</NAME> 

16: </FIELDDEFINITION> 

17: <FIELDDEFINITION> 

18: <NAME>Amount</NAME> 



19: </FIELDDEFINITION> 

20: <FIELDDEFINITION> 

21: <NAME>Void Check</NAME> 

22: </FIELDDEFINITION> 

23: <FIELDDEFINITION> 

24: <NAME>Additional Data</NAME> 

25: </FIELDDEFINITION> 

26: </FIELDDEFINITIONLIST> 

27: <CATEGORIES> 

28: <CATEGORY>PPAY< /CATEGORY > 

29: </CATEGORIES> 

30: 

31: <CMADAPTERCLASS>com.ffusion.fileimporter.fileadap 
ters. custom. 

CustomPPayCheckRecord</CMADAPTERCLASS> 
32: </OUTPUTFORMAT> 
33: < /ADAPTERS ETTINGS> 
34: </FILEADAPTER> 
35: </XML> 

[0247] while the invention is described in some detail with spe- 
cific reference to a single-preferred embodiment and cer- 
tain alternatives, there is no intent to limit the invention to 
that particular embodiment or those specific alternatives. 



For instance, those skilled in the art will appreciate that 
modifications may be made to the preferred embodiment 
without departing from the teachings of the present in- 
vention. 



